Re: Recommending packages via virtual package
On Wed, 2020-04-15 at 01:07 +0200, David Kalnischkies wrote:
> Frankly, I was just honest as this thread-style annoys the heck out of me,
> but I guess I could have worded that a bit differently to make more obvious
> what I mean. So, let me explain where my anger comes from:
>
> You started with:
> | not sure if this has been discussed elsewhere, but I recently noticed
> | a change in APTs lookup for Recommends. Maybe also for other dependencies.
>
> So, you "asked for help", but not in debugging APT or related, but in finding
> where this change/bug in APT is discussed, providing your opinion on why the
> change should be fixed/reverted ("policy", "wide spread usage") and asking
> others to join in ("What are your thoughts on that?" [that = the change]).
>
> Or in other words: You were asking for help in forming a mob to force the bad
> apt devs into behaving (slightly exaggerated for effect).
>
> That your example is both not showing the described problem and easy to
> reason about showing that the bug you have postulated doesn't exist is
> "just" icing on the "It is obviously APTs fault" cake.
>
>
> It isn't what you meant to say of course, but you would be surprised how often
> that style is used rather than the intended "I have no idea why APT does that
> here, could someone please explain it?".
It was my fault that I didn't test and debug properly before writing the e-mail.
I'd known from other users that the behavior worked before, but I was too dumb
to reproduce it.
I never intended to blame anyone or form a mob... Maybe you should not try to
read too much between the lines, and just try to accept that we all make
mistakes or have misunderstandings.
I'm willing to accept my mistakes, but I always try to keep the tone nice. Even
when I'm annoyed by someone.
If we could all just try to be nice to each other the world would be a better
place...
Regards
Markus
--
lazyfro...@debian.org
https://lazyfrosch.de
Re: RFC: Standardizing source package artifacts build paths
Sean Whitton: > Hello, > > On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote: > >> Guillem and I have debated this and come to a solution, which we believe >> will be able to address the concerns about the path being "hidden". It >> also enables us to simplify parts of the migration in some cases. > > Thank you for your continued efforts! > Thanks. :) >> The short version of that solution is to enable debhelper to expose the >> relevant directories where you want it and under debian/.build at the >> same time (the latter being a symlink to the former)[1]. > > Sorry, but don't you mean the former (non-dotdirs) being a symlink to > the latter (.build)? > Originally, no. Though I think I will leave it unspecified while we experiment to see if I become wiser on the topic than I am today. My thought was this would enable debhelper to see that the directory was exposed and look it up without additional state tracking (which would in turn enable debhelper to ensure that we clean up properly since both "ends" must be removed during clean). But worst case, it will cost me a compat level to flip the order of the two if the epiphany comes to me after initial deployment. ~Niels
Source of shared runners containers used in salsa CI system
Hi I see salsagitlab ci is using docker containers for its shared runners like for instance in https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/.gitlab-ci.yml#L23 How are these containers images built ? I specifically wanted to check if xz-utils is included or not in the debian:buster image. Regards Manu -- You know an upstream is nice when they even accept m68k patches. - John Paul Adrian Glaubitz
Re: Source of shared runners containers used in salsa CI system
On Wed, 2020-04-15 at 10:03 +0200, Emmanuel Kasper wrote: > I see salsagitlab ci is using docker containers for its shared runners > > like for instance in > > https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/.gitlab-ci.yml#L23 > > How are these containers images built ? > > I specifically wanted to check if xz-utils is included or not in the > debian:buster image. That should be the standard docker images in Docker Hub's library: https://hub.docker.com/_/debian Source: https://github.com/docker-library/official-images/blob/master/library/debian Tooling and artifact source (on GitHub) is linked there. You can just do: docker pull debian:buster -- lazyfro...@debian.org https://lazyfrosch.de
Bug#956797: ITP: phoc -- Wayland compositor for mobile phones
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris * Package name: phoc Version : 0.1.7 Upstream Author : Purism SPC * URL : https://source.puri.sm/Librem5/phoc * License : MIT, LGPL-2.1+ and GPL-2+ Programming Lang: C Description : Wayland compositor for mobile phones Tiny wayland compositor based on wlroots for use on mobile phones like the Librem 5. I take the responsibility for maintaining this package.
What should I learn for applications befor, C or C++?
Hello. Today, my main programming language is Python. I have worked with other programming languages. I'd like to become a stronger developer, and be able to write performance code. I'm interested in developing applications for Windows and Linux. I was interested in C#. But this is not fully supported by Linux, unfortunately. I hate system programming. What should I learn first? C or C++? Thanks in advance!
Re: What should I learn for applications befor, C or C++?
On Wed, 2020-04-15 at 16:05 +0300, Constantine Ryzhikov wrote: > Hello. > Today, my main programming language is Python. I have worked with > other > programming languages. > I'd like to become a stronger developer, and be able to write > performance code. > I'm interested in developing applications for Windows and Linux. > I was interested in C#. But this is not fully supported by Linux, > unfortunately. > I hate system programming. > What should I learn first? C or C++? > Thanks in advance! I would suggest learning C++ first. Although C and C++ both require memory management, C++ does a lot of the legwork for you, and also abstracts away a number of things that would have to be spelled out explicitly in C (vtables, destructors, etc.) By the way, C# has at least partial support on Linux, through the Mono project. Happy hacking! Kyle
Re: Bits from the DPL for March 2020
Hello Sam, Am Montag, 6. April 2020, 11:34:12 CEST schrieb Sam Hartman: > Thinking about Covid-19 and what this means for the world has taken up > much of my emotional bandwidth in March. I haven't read anything that describes what has happened to me as matching like this. *distance hugs* Eike signature.asc Description: This is a digitally signed message part.
Re: What should I learn for applications befor, C or C++?
On Wed, 2020-04-15 at 16:05 +0300, Constantine Ryzhikov wrote: > Hello. > Today, my main programming language is Python. I have worked with > other > programming languages. > I'd like to become a stronger developer, and be able to write > performance code. > I'm interested in developing applications for Windows and Linux. > I was interested in C#. But this is not fully supported by Linux, > unfortunately. My understanding is that it's well supported on Linux - both by Mono and by .NET Core. > I hate system programming. > What should I learn first? C or C++? > Thanks in advance! If you hate system programming, why pick a system programming language? But if you want to do it anyway, Rust is another option to consider. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#956836: ITP: bitwarden -- fully open-source, cross-platform password manager
Package: wnpp Severity: wishlist Owner: Calum McConnell * Package name: bitwarden Version : 1.17.2 * URL : http://www.bitwarden.com/ * License : GPL-3 Programming Lang: Typescript Description : fully open-source, cross-platform password manager == Long description == Bitwarden is an open-source password manager that syncs securly between devices. The full stack is libre software, including the server, meaning one can host their own passwords instead of storing them for free on bitwarden.com's service. Passwords are stored encrypted on the server and on the client using an encryption key derived from the master password by PKBDF2 SHA-256, and encrypted using AES-256. Passwords are encrypted by the client before being sent to the cloud server: it is not possible to determine the unencrypted passwords from the cloud server, unless an attacker already knows the user's master password. Bitwarden also supports saving of other data within the vault. However, saving large files on the bitwarden.com servers requires a premium subscription. This package contains the bitwarden client, which connects to a bitwarden server. == Justifications/Plans == Note: New to the world of packaging I think this package is very useful and relevant, because password managers are a must in order to remain secure using online accounts, and this is the only cross-platform, FOSS manager of which I am aware. I, for one, use it: I do have the premium subscription, but only to support the authors. This is my first Debian package, and as such I would appreciate support. I will need a sponsor: I do plan on finding one thru debian-mentors. I am not aware of any teams which would maintain this: it is a Node.js+electron application, though they also distribute a C# port for mobile devices. I would be happy to work with a team on this package, for I have little javascript experiance and no Electron experience. I plan on using Git and Git-buildpackage to maintain this, because I have grown used to having a full revision history, and I quite like working on several devices. Salsa link is here: https://salsa.debian.org/CalumMcConnell-guest/bitwarden. The branch structure is that recommended by gbp documentation: master is upstream, debian/sid is the contents of the up-to-date debian packaging. I plan on using debmake to make the debian/ files.
For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))
Hi, there will be a formal summary of our sprint which I'd describe with the short summary that we have approached in one week more than in usual two monthes work. Thanks a lot to all who contributed - especially thanks for an enormous support from ftpmaster (we had huge batches of accepted packages in less than 24 hours!) Since the COVID-19 situation is by no means settled and as usual successful work tends to create even more work we want to continue our effort. So those who are interested to contribute the contact points below remain valid. We also want to continue with video meetings. As a first date we try an end-of-week meeting on Fridays (I'm open for better suggestions why Friday is not so good and a different day of week should be choosen). Here is a poll for the exact time for next Friday: http://whenisgood.net/hd53twx Looking forward to see you next Friday Andreas. On Fri, Mar 27, 2020 at 08:59:50PM +0100, Andreas Tille wrote: > Dear Debian Community, > > There will be an virtual (online) COVID-19 Biohackathon from April 5-11, > 2020 and the Debian Med team invite you help us improve biomedical FOSS > and the tools/libraries that support those projects. > > Most tasks do not require any knowledge of biology or medicine, and all > types of contributions are welcome: bug triage, testing, documentation, > CI, translations, packaging, and code contributions. > > 1. Debian related bugs are viewable at [covid19-bugs] > > 2. Software awaiting packaging is listed at [covid-19-packages], please > respond to the RFP with your intent so we don't duplicate work > > 3. You can also contribute directly to the upstream packages, linked > from the Debian Med COVID-19 task page at [covid-19-packages]. Note: > many biomedical software packages are quite resource limited, even > compared to a typical FOSS project. Please be kind to the upstream > author/maintainers and realize that they may have limited resources to > review your contribution. Triaging open issues and opening pull requests > to fix problems is likely to be more useful than nitpicking their coding > style. > > 4. Architectures/porting: Please focus on amd64, as it is the primary > architecture for biomedical software. A secondary tier would be arm64 / > ppc64el / s390x (but beware the endian-related issues on s390x). From a > free/open hardware perspective it would be great to see more riscv64 > support, but that is not a priority right now > > 5. The Debian Med team is also trying to improve the availability of > automated biomedical pipelines/workflows [robust-workflows] using the > Common Workflow Language open standard. The reference implementation of > CWL is written in Python and there are many open issues ready for work > that don't require any biomedical background [cwltool-issues] > > 6. It is very easy to contribute to Debian Med team. We have a lowNMU > policy for all our packages. Merge requests on Salsa are usually > processed quickly (but please ping some of the latest Uploaders of the > package to make sure it will be noticed). Even better if you ask for > membership to the team and push directly to the salsa repository. > > 7. The [debian-med-team-policy] should answer all questions how to > contribute. > > The main COVID-19 biohackathon is being organized at [covid-19-bh20] and > for Debian's participation we are using [salsa-covid-19-bh20] > > [covid-19-bugs] https://blends.debian.org/med/bugs/covid-19.html > > [covid-19-packages] https://blends.debian.org/med/tasks/covid-19 > > [covid-19-bh20] https://github.com/virtual-biohackathons/covid-19-bh20 > > [salsa-covid-19-bh20] > https://salsa.debian.org/med-team/community/2020-covid19-hackathon > > [robust-workflows] https://doi.org/10.1007/s41019-017-0050-4 > > [cwltool-issues] https://github.com/common-workflow-language/cwltool/issues > > [COVID-19-advice] > https://www.who.int/emergencies/diseases/novel-coronavirus-2019/advice-for-public > > [debian-med-team-policy] https://med-team.pages.debian.net/policy/ > > Sincerely, > > Michael R. Crusoe on behalf of the Debian-Med team > > (and Andreas Tille on behalf of Michael R. Crusoe ;-) ) > > > > -- > Michael R. Crusoe > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl56BmsACgkQPCZ2P2xn > 5uJzYBAAuo7koTEkxqRexkdg4T/xSO1s7AwW+NGRFPwQnT2NoIwBcXCDkU7xYGF2 > ACbswiDJNwSevrP4oV89E0OLpncJbnPP9bRwFO+Sppuo6AhgAhJsxn8N6tN4DDki > 50E+riYUqNfBakRKOzHVFTHy2H5BaOsDxJGMFoYW0twZCbWEoLJr9jMbcPHoDpyn > M+cMEQ6yUYwgLA08p67P2Ts9GsnYt30czZSmXYG88fjadhd2hQ/TvhykrRBGnL2d > QjcdPivoo+Er8h7LRrRzWAS1j5lPJOsQ9EJvMu3bns86Jk4yS0uX5Rcen+TNPEQ9 > /ui+MtNY29XPwNTOfE564X4K6GMlPmQ+NnAghkzYOsKhlXuo54sRQhmfPR88fSBx > +hWddj3SNfb3NJlOrUbXDz4HKmq8jwPj7U5o13ajfMS+ylTER8j+rHNIdqjlIZPo > xs7vw5sn3hBNObfq8OKScOBbFe6GVi9Pl8sGKZSW7GebumeHRtrSKVMQvgBxEdup > a70kuG+c+BiBvX6IJEtMlDe4nZ418fI61sf7TM3lrSWFJ/FfRvfwUzmbm3ripf+T > tKTkqi0fBG2MhIaiCSz2jsZXzaoQX5huVYZbeaaskJaa/IP+T/Rc5N2kD+wPQZyC > dYi45D
Bug#956839: ITP: kgx -- Simple user-friendly terminal emulator for the GNOME desktop
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris * Package name: kgx Version : 0.2.1 Upstream Author : Zander Brown * URL : https://gitlab.gnome.org/ZanderBrown/kgx * License : GPL-3+ Programming Lang: C Description : Simple user-friendly terminal emulator for the GNOME desktop Kings Cross is a simple terminal emulator for GNOME that adjusts nicely to small screen sizes and touch usage. For those running Debian on mobile phones, it will be a useful addition to Phosh, which I'm packaging too. I take the responsibility for maintaining this package.
Re: Source of shared runners containers used in salsa CI system
* Markus Frosch: > On Wed, 2020-04-15 at 10:03 +0200, Emmanuel Kasper wrote: >> I see salsagitlab ci is using docker containers for its shared runners >> >> like for instance in >> >> https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/.gitlab-ci.yml#L23 >> >> How are these containers images built ? >> >> I specifically wanted to check if xz-utils is included or not in the >> debian:buster image. > > That should be the standard docker images in Docker Hub's library: > https://hub.docker.com/_/debian > > Source: > https://github.com/docker-library/official-images/blob/master/library/debian > > Tooling and artifact source (on GitHub) is linked there. > > You can just do: > docker pull debian:buster Are these Debian-produced images nowadays? (Just because Docker says something is “official” doesn't mean that the content is produced by the trademark owner.)
Re: Source of shared runners containers used in salsa CI system
On Wed, 2020-04-15 at 21:59 +0200, Florian Weimer wrote: > > That should be the standard docker images in Docker Hub's library: > > https://hub.docker.com/_/debian > > Source: > > https://github.com/docker-library/official-images/blob/master/library/debian > > Tooling and artifact source (on GitHub) is linked there. > > You can just do: > > docker pull debian:buster > > > Are these Debian-produced images nowadays? > > (Just because Docker says something is “official” doesn't mean that > > the content is produced by the trademark owner.) Maintained by tianon and paultag AFAIK, but they are not built on Debian infra. -- lazyfro...@debian.org https://lazyfrosch.de
Re: Re: What should I learn for applications befor, C or C++?
There is still NetCore, but I cannot use this with Python.
Bug#956867: ITP: nmrpflash -- firmware flash utility for Netgear devices
Package: wnpp Severity: wishlist Owner: Damyan Ivanov * Package name: nmrpflash Version : 0.9.14-16-ge95526d Upstream Author : Joseph Lehner * URL : https://github.com/jclehner/nmrpflash * License : GPL-3+ Programming Lang: C Description : firmware flash utility for Netgear devices nmrpflash uses Netgear's NMRP protocol (http://www.chubb.wattle.id.au/PeterChubb/nmrp.html) to flash a new firmware image to a compatible device. It has been successfully used on a Netgear EX2700, DNG3700v2, R6220, R7000, D7000, WNR3500, R6400 and R6800, but is likely to be compatible with many other Netgear devices. Packaging will be developed at https://salsa.debian.org/debian/nmrpflash
