Re: Making Linux distro with Debian
On Sat, Nov 21, 2020 at 01:39:10AM +0300, ajsjajis eihwjshs wrote: >Its legal to making Linux distro and sharing with changing Debian logos >codes etc. Yes, it is legal, absolutely. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Library won't link
Hi, For the past year, I've been (on and off) working with ola upstream on getting new-gcc (first 9, then 10) and python3 issues resolved, so that I would be able to get it into bullseye again. We're almost there, except for one thing that mystifies me. As part of the autopkgtest, I build a small program that initializes libola to make sure that a basic initialization works. This worked previously, but now fails with: autopkgtest [15:27:45]: test command6: - - - - - - - - - - stderr - - - - - - - - - - /usr/bin/ld: /tmp/cczs0VkU.o: warning: relocation against `_ZTVN3ola2io18LoopbackDescriptorE' in read-only section `.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]' /usr/bin/ld: /tmp/cczs0VkU.o: in function `main': hw.cc:(.text+0x11): undefined reference to `ola::io::LoopbackDescriptor::LoopbackDescriptor()' /usr/bin/ld: hw.cc:(.text+0x24): undefined reference to `ola::client::OlaClient::OlaClient(ola::io::ConnectedDescriptor*)' /usr/bin/ld: hw.cc:(.text+0x30): undefined reference to `ola::client::OlaClient::Setup()' /usr/bin/ld: hw.cc:(.text+0xc1): undefined reference to `ola::client::OlaClient::~OlaClient()' /usr/bin/ld: hw.cc:(.text+0xe0): undefined reference to `ola::client::OlaClient::~OlaClient()' /usr/bin/ld: /tmp/cczs0VkU.o: in function `ola::io::BidirectionalFileDescriptor::~BidirectionalFileDescriptor()': hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0xf): undefined reference to `vtable for ola::io::BidirectionalFileDescriptor' /usr/bin/ld: hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0x1d): undefined reference to `vtable for ola::io::BidirectionalFileDescriptor' /usr/bin/ld: /tmp/cczs0VkU.o: in function `ola::io::ConnectedDescriptor::~ConnectedDescriptor()': hw.cc:(.text._ZN3ola2io19ConnectedDescriptorD2Ev[_ZN3ola2io19ConnectedDescriptorD5Ev]+0xf): undefined reference to `vtable for ola::io::ConnectedDescriptor' /usr/bin/ld: hw.cc:(.text._ZN3ola2io19ConnectedDescriptorD2Ev[_ZN3ola2io19ConnectedDescriptorD5Ev]+0x1d): undefined reference to `vtable for ola::io::ConnectedDescriptor' /usr/bin/ld: /tmp/cczs0VkU.o: in function `ola::io::LoopbackDescriptor::~LoopbackDescriptor()': hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0xf): undefined reference to `vtable for ola::io::LoopbackDescriptor' /usr/bin/ld: hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0x1d): undefined reference to `vtable for ola::io::LoopbackDescriptor' /usr/bin/ld: hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0x31): undefined reference to `ola::io::LoopbackDescriptor::Close()' /usr/bin/ld: warning: creating DT_TEXTREL in a PIE collect2: error: ld returned 1 exit status autopkgtest [15:27:45]: summary (as observed on https://salsa.debian.org/wouter/ola/-/jobs/1173462#L1297) >From what I can make out, the first message happens when a file is compiled without -fPIC and then linked into a shared library. This would be surprising if that is the reason, for libola is built using libtool throughout, and trying the build on stable works with no problem whatsoever. What am I missing? -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: ik wil meedoen en een antwoord van een menselijke e-mail accoutn ?
Lingua franca after the dutch text On Sun, Nov 22, 2020 at 12:13:34AM +0100, Richard wrote: > Haloo Debian, Hallo Richard, > Ik heb wat e-mails verstuur den wil nu eindelijjk meedoen maar dan moet > iemand wel reageren op mijn e-mails? Ja, aansluiting vinden is uitdagend. Wat tips: * Heb iets wat je leuk/belangrijk/goed/interresant vind * Maak dat kenbaar * Kijk wat er gebeurd * Ga er vanuit dat er meerdere pogingen nodig zijn * Er is een nederlandstalige mailinglist debian-user-du...@lists.debian.org * Mailinglist debian-events...@lists.debian.org is dat ook wel * Engels is echter de gangbare taal in Debian * Ben ge-aboneerd op de ML waar je berichten naar toe stuurt * Weet dat jij zelf moet afhalen, verwacht niet dat het je gebracht wordt * Ga voor wisselwerking, dus geven en nemen English: | } I want to get involved, but I feel ignored | Advice on how to get forward > Groeten, > Richard Waterbeek > Nederland Regards Geert Stappers Internet -- Silence is hard to parse
Re: Library won't link
On 2020-11-22 11:29 +0200, Wouter Verhelst wrote: > For the past year, I've been (on and off) working with ola upstream on > getting new-gcc (first 9, then 10) and python3 issues resolved, so that > I would be able to get it into bullseye again. We're almost there, > except for one thing that mystifies me. > > As part of the autopkgtest, I build a small program that initializes > libola to make sure that a basic initialization works. This worked > previously, but now fails with: > > autopkgtest [15:27:45]: test command6: - - - - - - - - - - stderr - - - - - > - - - - - > /usr/bin/ld: /tmp/cczs0VkU.o: warning: relocation against > `_ZTVN3ola2io18LoopbackDescriptorE' in read-only section > `.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]' > /usr/bin/ld: /tmp/cczs0VkU.o: in function `main': > hw.cc:(.text+0x11): undefined reference to > `ola::io::LoopbackDescriptor::LoopbackDescriptor()' > /usr/bin/ld: hw.cc:(.text+0x24): undefined reference to > `ola::client::OlaClient::OlaClient(ola::io::ConnectedDescriptor*)' > /usr/bin/ld: hw.cc:(.text+0x30): undefined reference to > `ola::client::OlaClient::Setup()' > /usr/bin/ld: hw.cc:(.text+0xc1): undefined reference to > `ola::client::OlaClient::~OlaClient()' > /usr/bin/ld: hw.cc:(.text+0xe0): undefined reference to > `ola::client::OlaClient::~OlaClient()' > /usr/bin/ld: /tmp/cczs0VkU.o: in function > `ola::io::BidirectionalFileDescriptor::~BidirectionalFileDescriptor()': > hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0xf): > undefined reference to `vtable for > ola::io::BidirectionalFileDescriptor' > /usr/bin/ld: > hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0x1d): > undefined reference to `vtable for > ola::io::BidirectionalFileDescriptor' > /usr/bin/ld: /tmp/cczs0VkU.o: in function > `ola::io::ConnectedDescriptor::~ConnectedDescriptor()': > hw.cc:(.text._ZN3ola2io19ConnectedDescriptorD2Ev[_ZN3ola2io19ConnectedDescriptorD5Ev]+0xf): > undefined reference to `vtable for ola::io::ConnectedDescriptor' > /usr/bin/ld: > hw.cc:(.text._ZN3ola2io19ConnectedDescriptorD2Ev[_ZN3ola2io19ConnectedDescriptorD5Ev]+0x1d): > undefined reference to `vtable for ola::io::ConnectedDescriptor' > /usr/bin/ld: /tmp/cczs0VkU.o: in function > `ola::io::LoopbackDescriptor::~LoopbackDescriptor()': > hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0xf): > undefined reference to `vtable for ola::io::LoopbackDescriptor' > /usr/bin/ld: > hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0x1d): > undefined reference to `vtable for ola::io::LoopbackDescriptor' > /usr/bin/ld: > hw.cc:(.text._ZN3ola2io18LoopbackDescriptorD2Ev[_ZN3ola2io18LoopbackDescriptorD5Ev]+0x31): > undefined reference to `ola::io::LoopbackDescriptor::Close()' > /usr/bin/ld: warning: creating DT_TEXTREL in a PIE > collect2: error: ld returned 1 exit status > autopkgtest [15:27:45]: summary > > (as observed on > https://salsa.debian.org/wouter/ola/-/jobs/1173462#L1297) > >>From what I can make out, the first message happens when a file is > compiled without -fPIC and then linked into a shared library. This would > be surprising if that is the reason, for libola is built using libtool > throughout, and trying the build on stable works with no problem > whatsoever. > > What am I missing? I think this happens because g++ passes --as-needed to the linker in unstable, but not in stable. Your test program is compiled with g++ -o linktest $(pkg-config --cflags --libs libola) debian/tests/hw.cc and that adds -lola at the wrong place in the commandline. According to the binutils documentation, --as-needed has this effect: , | Object files or libraries appearing on the command line _after_ the | library in question do not affect whether the library is seen as needed. | This is similar to the rules for extraction of object files from | archives. '--no-as-needed' restores the default behaviour. ` So, g++ -o linktest debian/tests/hw.cc $(pkg-config --cflags --libs libola) is probably you want instead. HTH, Sven
Bug#975447: ITP: foonathan-memory -- STL compatible C++ memory allocator library
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org, t...@gaussglocke.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: foonathan-memory Version : 0.6.2 Upstream Author : Jonathan Müller * URL : https://github.com/foonathan/memory * License : zlib Programming Lang: C++ Description : STL compatible C++ memory allocator library The default STL allocator model has various flaws, for example you cannot easily share a single allocator for multiple types. This library is one of many proposed solutions for the shortcomings of the standard allocator, which unlike many other solutions does not require changes in the STL itself. foonathan-memory is a dependency for the open source DDS implementation FastRTPS, which in turn serves as the default transport layer for the new Robot OS version 2. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAl+6XjMACgkQ+C8H+466 LVm0WwwAyz3PuTt9tBHEOhSjM6sVwnMzu1iLDgcZW4BnZa9K0HYQCnfFEckOjarZ Txmy7xw1m2hRxaoLlMhRETqsUSqbWZR0SxplZ5v5kI90vA4x7pK8UmiZqeUiDBwS PO7UQc47CEHTbl5ninilmAe/B38ehPczJhKjD1TPrVr+Xw+qiBAKT7Qg14MXGQwS E6eNKJSnSdtvFUUsMr0Qo0rV5oZu53+ELOUkNZpghPEYzxrFhovOHvCnFe9/f8g2 YPa1zBi94Bv25m0IxSM0KSgq/jRSiDj4hgEZlFObuVYIg3hPPkfPZjJ4yH8aom72 /vA/l5V5UzEs++KG1MAomvoHaM+mj88jwyJAyd5zXAy8S17cx6MP85GYMokYsO/S vL95VK+PoKI4i8zupIQF8dGR6g/hl6pffpDzwfXeIQU/FLHfsZpoBeZvgJX41S25 TOAkzGsgFgcUqWi5AA2MwttNXefculit8vwhrezWjivUQE4EgwPaeKFjt2QC4QXz LOdPl/oT =W7Z1 -END PGP SIGNATURE-
Re: Making Linux distro with Debian
Okay, thanks. 22 Kas 2020 Paz 10:52 tarihinde Wouter Verhelst şunu yazdı: > On Sat, Nov 21, 2020 at 01:39:10AM +0300, ajsjajis eihwjshs wrote: > >Its legal to making Linux distro and sharing with changing Debian > logos > >codes etc. > > Yes, it is legal, absolutely. > > -- > To the thief who stole my anti-depressants: I hope you're happy > > -- seen somewhere on the Internet on a photo of a billboard >
Re: Library won't link
Hi Sven, On Sun, Nov 22, 2020 at 11:44:42AM +0100, Sven Joachim wrote: > On 2020-11-22 11:29 +0200, Wouter Verhelst wrote: > > What am I missing? > > I think this happens because g++ passes --as-needed to the linker in > unstable, but not in stable. Your test program is compiled with > > g++ -o linktest $(pkg-config --cflags --libs libola) debian/tests/hw.cc > > and that adds -lola at the wrong place in the commandline. According to > the binutils documentation, --as-needed has this effect: > > , > | Object files or libraries appearing on the command line _after_ the > | library in question do not affect whether the library is seen as needed. > | This is similar to the rules for extraction of object files from > | archives. '--no-as-needed' restores the default behaviour. > ` > > So, > > g++ -o linktest debian/tests/hw.cc $(pkg-config --cflags --libs libola) > > is probably you want instead. I was going to say "but 913704", but somehow I lost that change... D'oh. That would explain it, obviously. Thanks! -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Andreas, On 19-11-2020 08:22, Andreas Tille wrote: >> I have the strong impression that we're talking past each other. The log >> message that you quoted in your initial e-mail said "uninstallable on >> arch *, not running autopkgtest there". This means the test is not >> triggered *and* that fact will *not* block the package. However, you are >> now saying we're scheduling the test which fails. That's a completely >> different category. > > What I mean when looking at the armhf log[1] this starts with> > autopkgtest [21:45:36]: host ci-worker-armhf-01; command line: > /usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo '"'"'drop-seq > unstable/armhf'"'"' > /var/tmp/debci.pkg 2>&1 || true' --user debci > --apt-upgrade '--add-apt-source=deb http://incoming.debian.org/debian-buildd > buildd-experimental main contrib non-free' --add-apt-release=experimental > --pin-packages=experimental=src:plexus-archiver --output-dir > /tmp/tmp.R29JBBc7iX/autopkgtest-incoming/unstable/armhf/d/drop-seq/7114930 > drop-seq -- lxc --sudo --name ci-265-4a1a79f8 autopkgtest-unstable-armhf This log was used to test plexus-archiver. Indeed, when we schedule tests for other packages, we don't check if the package we schedule is installable. I don't think there's much harm though, as this is not a regression, so this isn't in the way of any maintainer. > For me that's an attempt to run a test when apt starts getting files. > That's what I was talking about. Ok. Do you think this is a problem somehow? > I think this has changed now since > for arm64[2]. This log is way shorter and ends with > > run-unit-testSKIP Test lists explicitly supported architectures, but > the current architecture amd64 isn't listed. That's because the maintainer added the Architecture field to debian/tests/control. > The result is "neutral" - and I think you was talking about the > latter which seems to be relatively new when looking at the overview > page[3]. The log from 2020-11-08 looks similar to the armhf log > above but since 2020-11-11 it has the neutral result (which is > what I tried to suggest). That's for a different reason though, that was due to the maintainer. I think you are (or were) suggesting we should fix this automatically. >>> I'm wondering whether it would >>> be easy to find out in advance whether it is possible to install that >>> package on that architecture (for instance by an UDD query whether >>> all dependencies are available or whatever) and just stop if it turns >>> out that the package is not installable. >> >> Yes, we can (and do) that, but what then? If the non-installability is a >> regression, we should block the package. > > This is definitely a good question. > >> If the non-installablility is >> already existing, the package should just move on. We already do that >> (or at least try very hard). So, which *exact* use case do you consider >> here (real life examples help). > > I think my real life example drop-seq was a good one. I still don't see the problem. You're right, that test was scheduled in vain, but was any harm done (except climate heating)? >>> As I tried to say above: I would prefer to find out before apt runs >>> in a fully setup test environment whether the package is installable >>> at all. >> >> As I tried to say above, we already don't schedule the test in *most* >> cases and as far as I'm aware, we only have some issues where arch:all >> packages are involved. In some cases, I don't think there is a "right" >> answer, so we need to get the most acceptable solution. > > That's true and I agree that the decision whether the missing of a > package has to be considered a failure or not is a hard one. I think the exact use case you gave above with drop-seq could be fixed, but there are quite a lot more pressing use cases I want to work on. >>> My idea is to find out whether a package is installable on some >>> architecture and add a new test result say "NOT_INSTALLABLE" or >>> "NOT_INSTALLABLE_ON_ARCH" which is considered "neutral" as test result. >> >> We don't schedule those cases we can catch. So we don't need to have a >> new state. If we can find the exact problem you're describing we can try >> to add it to the set we don't trigger. (By the way, are you aware of the >> skip-not-installable restriction? > > No, sorry. Where can I read about it? In the autopkgtest spec: https://salsa.debian.org/ci-team/autopkgtest/-/raw/master/doc/README.package-tests.rst But again: >> It's not great, as it hides real >> issues, but could be a solution for a class of packages, maybe the ones >> you worry about). Paul signature.asc Description: OpenPGP digital signature
Bug#975495: ITP: gping -- Ping, but with a graph.
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Rust Maintainers -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: gping Version : 0.1.7 Upstream Author : Tom Forbes * URL : https://github.com/orf/gping * License : MIT Programming Lang: Rust Description : Ping, but with a graph. Continuously runs a ping against a specified host, plotting a latency chart in the terminal in realtime. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+63x8RHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7Msikg/+JCYTd9HTHJqMQvQPrLEr2RaWLKW8uWym Ksnv3ZMhFsU6Q5bDK5ISsvJWkjr7pNpTsiBnnX+wUm+d3+0jmPbifKPMAY/bdJ72 nfsdm4HWBoZ/EyYdGVB1g839W8QFRJ19EuXACVlpsaTeaUnMwnYiJhezHXkLL99e ySgrpHkAHWjbclEW3QPA18fvj3I3vqss5ftSCnd576cYpnm0+GK2xymOn3v+4Op0 PpU2g5yZCSlDOF6RLQ+VfOdL0LaeCPaYQRe544Uw6Y8Ax7qvqzSgfrE2lFjgoiFv 3ROwvWZU4jfs6kEW5gNd1Cjmhb9N+FAzzQduQA2hPYa/IQG4nhnGeks6xmyWOCvC 9pw4MJmqC/g3jPdS3+673HPF72dhEqHRFFq982AeUI0oSKIvA4Ie2dQt/k22zqej 5gCeR/0zAaREul4J+r3J73c4pFobsDecJcdNTlMLzvZ2DcG/hogDdWWqB8uY8nXF 8qqkj1c9DmLqmm8GR+MGvieK2dvABOdUoDjjeMQxZXvaZobBfNtBuZ1ka5PUTOud pQkSaE9rFItdI9Q3SG7Ia8TyZt/0WZER2Dy9cg+IrIhtGk85GK8el3qPiM6am/iQ ZDwCCYr5nmUmdlwxuiacQ0mTb/HryJj8Gs4lJT2vpUiaWlzmXr3BDPU90Af9OwFR f4v38/lr9lc= =pLbK -END PGP SIGNATURE-
Is that legal?
Hello, I will make a debian based linux distro. I will open website as soon as possible for my linux distro. But for now, I can't open because I don't have money to buy domain. I can open mail address with Google Workspace like "nickn...@debian.com". Can I use that mail address for 14 days (It's free for 14 days.) I will change that mail address when I can have money to buy domain. User, Newest
Bug#975497: ITP: multiplex -- View output of multiple processes, in parallel.
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: multiplex Version : 0.5.1 Upstream Author : Dan Kilman * URL : https://github.com/dankilman/multiplex * License : MIT Programming Lang: Python Description : View output of multiple processes, in parallel. View output of multiple processes, in parallel, in the console, with an interactive TUI. Also usable programatically, as a Python library. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+676QRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MsTFA//R19TtK/qdaoypVG3N0vSThN/lFr+bCBJ PSFYGKu/vm8U9vqQkMmUnaNPe4Wl0D8H1Q/M8IIHiHuZOFstX1l4AqSsbL643uA0 Kyb0I/Az9sIGx0H/MSYuQRoWb1GsAqJEzz5ljgWawZZ2Zf10jLIKNN1ifNNA5w4i lYvVGzytxRlzTmayUOi7sI+N5hjoYeQUOVOzoFsHLsIqrzHpFBgWNrcfFGinHGrJ Qu+oLG3D5O5d3A0dPEqzIOUqjv6jFMjhYazTqA/pFmiLSFNGg8t9c3PQKWx0ifWu Il26QZvrbEs1GHy1C2BGqJzLTR9WRm26BfHOMpOd/nEXoAB6jrZeb8nS7w2lspBn jeCuR3Siz72Y4/YLon3wcUF96XPVpola5pB65Uzf4Zq1tocEmSAsKwXJYFCBMEDu oKIkrfElCE23boAdBv0uIErnUSmSY4fJa6YVk3c2skNRZZx33ldpJi81aVUexnOQ DrVV0iPGRQd6JZHodoqz22LwGOm/LZUvHVapKt/kxoYH1XstEH3tnaAE3xtmXRed dXQdKQjZGT4dgDt9wiZEcutMgamlFRLQhhE2PAzDBOGfYkpsqVQ/oDCg2/2jmXVw P3q5MtRs9ZWZcPUbDZr+CDMl+aojO4MUOrgYysxmLY3ooyyhdHNMBK5gGM2hRGjl DAaAB4pUEoE= =0T9h -END PGP SIGNATURE-
Bug#975498: ITP: python-aiostream -- Generator-based operators for asynchronous iteration
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team Control: block 975497 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-aiostream Version : 0.4.1 Upstream Author : Vincent Michel * URL : https://github.com/vxgmichel/aiostream * License : GPLv3 Programming Lang: Python Description : Generator-based operators for asynchronous iteration aiostream provides a collection of stream operators that can be combined to create asynchronous pipelines of operations. It can be seen as an asynchronous version of itertools, although some aspects are slightly different. Essentially, all the provided operators return a unified interface called a stream. A stream is an enhanced asynchronous iterable. aiostream is a dependency of multiplex (ITP #975497) -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+6+e4RHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MsVCA//bVHfhooj83gcDiIxSRM0J1sBYooyKVTT tJMzrR8dDT3zMZoLzRRue/H+hZHYUyS/ruWSUKb/KFJgepkN2NYmQ2J9CwrjQvdw XT7KucxxDKNdUoQbZGRYjo6fVOapSqZPGfQGjTFwPLG4vnWMfu8ijxhumG+R/RmG cOmfF/Q+T9TSeaWXz2ze38qfysoYW2jXY/BHe0kX7FVTJXJBdAq4Rm3Xfgzo9f3D NSeCzV9TjZtfmSkhPOwziVcuY6jsyChxQL+QeRR0P7HZYEhOnrrCCEma9WtYKH7d xSEhE283FMz9Qd5qUeqOWQmNeKTKokYzBabyNXuQQdwAXUKx9PwgU0J+TmD6+gBQ YlUFe0XjtdM/vHKixseGb1Xtm5nlihCr8ep1HrTcw9A/Mhbrhwr+gnh1HjZcQ52S EimhV9die9x+9bFW0UfbO1ecyMeUHd+JH5/ldSwZzZUGDnHlF2ofHesBdhQCOV97 7KFV6Wx3dAJCpxpAY4KICzO7qc8ixKtvwWW+wqap1eKeyXZK3mqTo0+0jy/eUyRG yfLHrxs4DWUQA0W38dM0N0amWBvxUke+GFFjPtLTjl3I+rzjncBqmKmgleQuoYje V7MlI5lLCSH85+URWLoqKhGkj3i0VQuaoS8WmVVBKlDoYW0OiPDMjMPQO+TeXWDn StZ8TGDyc2M= =IOGl -END PGP SIGNATURE-
Bug#975499: ITP: python-easy-ansi -- terminal framework for colors, cursor control movements, and line/box drawing
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team Control: block 975497 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-easy-ansi Version : 0.3 Upstream Author : Joey Rockhold * URL : https://gitlab.com/joeysbytes/easy-ansi * License : MIT Programming Lang: Python Description : terminal framework for colors, cursor control movements, and line/box drawing Easy ANSI is a terminal framework API to give you an easy way to use colors, cursor control movements, and line/box drawing. It is not meant as a replacement to more full-featured frameworks (such as curses or urwid), but as a tool to quickly create nice-looking screens in your terminal window. You can even create animations with the cursor controls. easy-ansi is a dependency of multiplex (ITP #975497) -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+6+xURHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7Murqg/+Np2vUc4gysQLzLck2SoaaVQ5O0U2i2E9 WyR82JGdT4UjKAaLea88XccWvRYOT4MP3WgsIZxYKx72+MX4Q4D/qZ6nHpPdjvW9 W1lmnV/ZA9FZsxDLsxvLNP6NtloPuApPe/oEHoEHsWWGRO3GjNOACOCnbHXBOW7B uKr+Qp4NC9mz49AmzXqHJjFQpdQanZZKFW3CMRr1mHq4O/N4qZYtmww02s7qt+hM CEqKhjc/ODzXxWPibt8NLW+uCPno72VPuUvKUxftcrxc6np2mICJlty8R49JT9RW MKaHGNgd6vV5P1gUyK90mOO0+kAjVM8BGU1LY9c/TC6xbA7djw5Ku54aX8/2NUHG pUMX1cT5VcIROSglKvuz5TibmdvrTSB1gBHfURUy9moKTcIoUJx12w8Dap6o2kxF n1dpf1r+IsBEpELpmImGxPM7bE9fzCTu/Hx+5AKhzBP+vSOjYnUmfVAwMLWzaJmu AnX0HhbO5TJ3L77hQGyEyd3r4fixgE5rCYAyrHiVBfjCpGxpxRBxKev3Wdi7S6pi d+nwP78yDMZY1vC6RecYzaGUnOEhegMoL15BJ/PzJSGbmOcXgpRWHwPQGoCw1khV 6efrAd0dBpQDuQ3zhk1G05ubmfRbG7QV99dDZVjNzEJ+pX3QMuYo3+p10sHK3ahT hSh/NvsuvVg= =s5y4 -END PGP SIGNATURE-
Bug#975500: ITP: python-ansicolors -- Add ANSI colors and decorations to your strings.
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team Control: block 975497 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-ansicolors Version : 1.1.8 Upstream Author : Jonathan Eunice * URL : http://github.com/jonathaneunice/colors/ * License : ISC Programming Lang: Python Description : Add ANSI colors and decorations to your strings. A Python library to add ANSI colors and decorations to strings. ansicolors is a build dependency of multiplex (ITP #975497) -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+6/BgRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7Mt8chAAqKrmM3kjqFpclsuYvJyKWIs86CyjYMaF OVpEs1COYH9rzLApJq/bJk3FJMXMmSEe8vYzGf/CJEyTlx0hUJOYc2/4yVdCziNJ 0c5/Ql/niVL7aCroBkszLvuTV5lSjgwN65L0pTp2iBtqolby2FX1t/TWpaRitDo4 MKfezQsptKduT8HMbo4VVyms9Bl9E+RzOuCc3+SOvF0/dRv9Y/AyqsX8XIaxrWja LQlUk3dBBUuUxEnAxIbENg43crZA3gUuGd8d89WT0c/k9jMYHWfj70VOQsV/onFJ V2IpvFKnnmmI+WB5FMQK7z5CKizsyWyZ/vm/c5EVWhSfyTk+akymASS/ECIgKYhq ojSIWUtv+jtk3amPHPeVEiPcVF2dJ17JgmCgSk50+zXeZyJt5tdqayhrlig2z3TC m12LOHqEnLJA3Yd4pji2MzMeg91gu1YkLwRFgQFprszCU1d8by1N+2RJTO0xjfIe vCExQgIeEfzpuvGKp9Y/d88h+E2nwcrfNtdx/nRkzHgoDZJoqxuiJCxF1xaxM7CU wUMLjNOkepKSTmbI2T2yli4WzVsY5AfQr+RSTNUTIWCpRcZI9i0Q5H5eZBe86uXw YCcatRfelZr0VGN/TCaNnHjyc39e584V6Ubfhx3IxU2U5pztm/8V8/A/rdcsBtqH mFNN6ZG8F04= =NLWN -END PGP SIGNATURE-
Re: Is that legal?
On Sun, Nov 22, 2020 at 10:09 PM Türker Tuğra Subaşı wrote: > I will make a debian based linux distro. It might be a better option to use Debian instead, join the community and contribute new packages and fixes for the use-cases and issues you are interested in or encounter. https://www.debian.org/intro/help https://www.debian.org/blends/ > I can open mail address with Google Workspace like "nickn...@debian.com". Can > I use that mail address for 14 days (It's free for 14 days.) The Debian Project owns debian.com, so that domain will not be available to Google Workspace. The domain is reserved for use by Debian and it is solely used as a redirector to debian.org, so no email addresses will be added to it. Please note that the Debian trademark policy says "You cannot use Debian trademarks in a domain name, with or without commercial intent": https://www.debian.org/trademark If you decide not to join Debian, these pages may be useful in the process of creating a new distribution: https://www.debian.org/intro/free https://www.debian.org/trademark https://www.debian.org/logos/ https://www.debian.org/derivatives/ https://wiki.debian.org/Derivatives https://wiki.debian.org/Derivatives/Guidelines https://wiki.debian.org/DerivativesFrontDesk -- bye, pabs https://wiki.debian.org/PaulWise
Bug#975508: ITP: node-yaml -- Nodejs parser and stringifier for YAML standard
Package: wnpp Severity: wishlist Owner: Xavier Guimard X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-yaml Version : 1.10.0 Upstream Author : Eemeli Aro * URL : https://github.com/eemeli/yaml * License : ISC Programming Lang: JavaScript Description : Nodejs parser and stringifier for YAML standard yaml is a JavaScript parser and stringifier for YAML, a human friendly data serialization standard. It supports both parsing and stringifying data using all versions of YAML, along with all common data schemas. As a particularly distinguishing feature, yaml fully supports reading and writing comments and blank lines in YAML documents. This is a (optional) dependency of many packages like npm, node-coffee-loader, node-tap,... It's not easy to replace it by node-js-yaml since API and behavior are really different. node-yaml will be maintained under JS Team umbrella
Bug#975509: ITP: nbdime -- Jupyter Notebook Diff and Merge tools
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: nbdime Version : 2.1.0 Upstream Author : Jupyter Development Team * URL : https://nbdime.readthedocs.io/ * License : BSD Programming Lang: Python Description : Jupyter Notebook Diff and Merge tools nbdime provides tools for diffing and merging of Jupyter Notebooks. . * nbdiff - compare notebooks in a terminal-friendly way * nbmerge - three-way merge of notebooks with automatic conflict resolution * nbdiff-web - shows you a rich rendered diff of notebooks * nbmerge-web - gives you a web-based three-way merge tool for notebooks * nbshow - present a single notebook in a terminal-friendly way
Bug#975510: ITP: deepin-wallpapers -- DDE wallpapers
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : deepin-wallpapers Version : 1.6.14 Upstream Author : amazingfate * URL : https://github.com/linuxdeepin/deepin-wallpapers License : GPL-3+ Programming Lang: Makefile Description : DDE wallpapers When users are ready to set their own desktop background, Deepin Wallpaper provides many beautiful background pictures for users to choose. . It is part of Deepin software and DDE (Deepin Desktop Environment). I intend to co-maintain this package inside pkg-deepin group.
Re: Is that legal?
On Mon, 23 Nov 2020 00:53:27 +0300, Türker Tu?ra Suba?? wrote: >But for now, I can't open because I don't >have money to buy domain. If you can't even afford a domain name, please let me ask, how many people will be working on "your" distribution? Debian has a four-digit number of contributors and has a budget. Do you seriously think that you will be able to build your own distribution without spending any money and with a small number of contributors (if any) that will go beyond replacing the name? Gretings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#975510: ITP: deepin-wallpapers -- DDE wallpapers
On Mon, Nov 23, 2020 at 01:08:15PM +0800, hufeng wrote: > * Package name : deepin-wallpapers > Version : 1.6.14 > Upstream Author : amazingfate > * URL : https://github.com/linuxdeepin/deepin-wallpapers > License : GPL-3+ It doesn't look like GPL-3+ to me: ,--[ LICENSE ] All the source code reside in this repository are licensed under GPLv3. Photographs are licensed under 3 different licenses: 1. CC-BY-NC 3.0 for photographs in the deepin directory. 2. CC-BY-SA 3.0 for photographs in the deepin-community directory. 3. Photographs in the deepin-private directory are not permitted to use without authorization. ` I see no code in copyrightable amounts, just a short Makefile. /deepin/ is CC-BY-NC 3.0, which is non-free. /deepin-private/ tries to forbid even use (which a pure license cannot do), and bears no permission to distribute. /deepin-community/ has a good license, but I think I've seen at least one of the images elsewhere -- among default images on Windows. I can't check that right now (I won't have access to a Windows install for at least a week), so it might be just a similar photo of the same geological feature. Or they might have come from a common freely-licensed source. Also, the license grants rights to only photographs, while images in /deepin/ are non-photographic. This seems to me to be a bad use of the word rather than something intentional, though. On the other hand, some of the images are awesome! I especially like the "ghost forest" in -community, while the trees in -private have a nice pseudo-tiled look. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋⠀ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Re: Is that legal?
Türker Tuğra Subaşı writes: > I will make a debian based linux distro. I will open website as soon as > possible for my linux distro. But for now, I can't open because I don't > have money to buy domain. [...] > Is that legal? As long as you don't distribute binaries without the sources, I guess it is legal. -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
