Preparation for sprint and videoconference today, Wednesday 2021-02-17 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020)
Hi, on one hand this is the call for the next video conference of the Debian Med team that are an established means to continue the COVID-19 hackathon in April[1] on the other hand this is possibly some preparation for our sprint tomorrow[2]. For those who would like to join this videomeeting it will happen at https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=20210217T18&ah=1 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 These video meetings were started in the Debian Med Biohackathon[1]. The topic is what contributors have done in the past week and to coordinate the work for next week. Here are the reports of some past meetings: https://wiki.debian.org/DebianMed/Meeting/WeeklyCovid19 Everybody who is interested in joining the Debian Med sprint[2] is kindly invited to join this preparation meeting. Lets keep on the great work Andreas (unfortunately I will not make it today personally) [1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html [2] https://salsa.debian.org/med-team/community/sprints/-/wikis/202102_debian-med_sprint_online -- http://fam-tille.de
Re: Bug#982926: ITP Emilua
Control: reassign -1 wnpp Control: severity -1 wishlist On Ma, 16 feb 21, 14:43:36, d4n1 wrote: > Package: emilua > > Version: 0.2.1-1 > > > Intent to package Emilua. > > More about Emilua project in http://emilua.org/ > > Att, Reassigning to correct (pseudo-)package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Re: Split Packages files based on new section "buildlibs"
Quoting Andrej Shadura (2020-11-10 10:27:44) > On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote: > > > The current proposal is to reduce the main Packages.xz files size by > > > splitting[4] out all of the packages that are not intended for users, > > > writing those into an own file. Those packages would have a section of > > > "buildlibs", independent of their other properties. > > > Should (almost?) everything in the existing libdevel section move to > > the new buildlibs section? > > I wouldn’t say so. > > If I install, say, libftdi-dev, I expect to be able to do actual development > with it, for Debian or not. In fact, installing libftdi-dev would be the > first thing I do if I were to develop with the library. > > On the contrary, if I’m going to do some development with, say, clap (Rust > command-line arguments parser), I wouldn’t install librust-clap-dev; more > than that, if I actually did, I’d be very difficult for me to actually use it > to develop an app. Aha. Would it? I have the following in my ~/.cargo/config.toml: [source.deb] directory = "/usr/share/cargo/registry" [source.crates-io] replace-with = "deb" [net] offline = true Then I clone some upstream git repo that uses clap: git clone https://github.com/dotenv-rs/dotenv.git And then I run "cargo build". Every time I get a message like: error: no matching package named `foo` found I install librust-foo-dev until finally: Parent pid 535147, child pid 535148 Child process initialized in 30.93 ms Compiling proc-macro2 v1.0.18 Compiling unicode-xid v0.2.0 Compiling syn v1.0.12 Compiling dotenv v0.15.0 (/tmp/dotenv/dotenv) Compiling quote v1.0.7 Compiling proc-macro-hack v0.5.9 Compiling dotenv_codegen_implementation v0.15.0 (/tmp/dotenv/dotenv_codegen_implementation) Compiling dotenv_codegen v0.15.0 (/tmp/dotenv/dotenv_codegen) Finished dev [unoptimized + debuginfo] target(s) in 9.93s Parent is shutting down, bye... So how is this "very difficult"? The steps are the same as when I clone a Python upstream git repo and I get the message "ModuleNotFoundError: No module named 'foo'" -- I just install python3-foo and it will work. Same here with rust and the librust-foo-dev packages. I do not deny that many upstreams will tell developers to use cargo, pip, go get... whatever to manage their software. Personally, I rather avoid using these package managers and use the packages provided by Debian instead. There are real advantages over using the packages from Debian. Instead of relying on another 3rd party repository where anybody can upload anything, I benefit from the additional work put in by DDs to make sure that no garbage ends up in the archive. Rather than the "fast-paced" development style that seems to be modern these days, I prefer the stability and security that I get by sourcing all my code and libraries from the Debian archive. With Debian packages, I cannot really get typosquatted, I know that all software is DFSG-free and I know that I will receive security updates. This is not an argument against splitting "main" into several archives. I'm no big fan of this solution but maybe it should be done. What I want to make an argument for in this email though is, that I do not believe that our packages have no value outside compiling other Debian packages even for languages where upstream prefers its users to use their own package manager. There are many reasons to prefer the trusted Debian sources for quality, security and software freedom and if any split is done, it should not be made in a way that makes it harder for our users to install those packages. They have real value. At this point let me also give a big thank you to all the nodejs, python, rust etc package maintainers for taking on the tedious task of making Debian packages for software that is already present in another repo. It's really great stuff -- thanks a lot! cheers, josch signature.asc Description: signature
Re: Split Packages files based on new section "buildlibs"
On Wed, Feb 17, 2021 at 9:33 PM Johannes Schauer Marin Rodrigues wrote: [...] > And then I run "cargo build". Every time I get a message like: > > error: no matching package named `foo` found > > I install librust-foo-dev until finally: > > Parent pid 535147, child pid 535148 > Child process initialized in 30.93 ms >Compiling proc-macro2 v1.0.18 >Compiling unicode-xid v0.2.0 >Compiling syn v1.0.12 >Compiling dotenv v0.15.0 (/tmp/dotenv/dotenv) >Compiling quote v1.0.7 >Compiling proc-macro-hack v0.5.9 >Compiling dotenv_codegen_implementation v0.15.0 > (/tmp/dotenv/dotenv_codegen_implementation) >Compiling dotenv_codegen v0.15.0 (/tmp/dotenv/dotenv_codegen) > Finished dev [unoptimized + debuginfo] target(s) in 9.93s > > Parent is shutting down, bye... > > So how is this "very difficult"? The steps are the same as when I clone a > Python upstream git repo and I get the message "ModuleNotFoundError: No module > named 'foo'" -- I just install python3-foo and it will work. Same here with > rust and the librust-foo-dev packages. I do think it's "very difficult". You end up calculating dependency trees by hand, instead of an automatic program, like cargo, pip. How does it come for version satisfaction? For example a library version installed in system path conflicts the software you are developing. -- Shengjing Zhu
Re: Re: Split Packages files based on new section "buildlibs"
> The same applies to the GNOME/GTK stack, where Flatpak is the way to go > for active development. libgtk-3-dev is really only for building Debian > packages from their point of view, too. Perhaps, but what matters is not upstream's point of view but Debian user's point of view. My perception is that when C/C++ users on debian want a library to compile stuff against their first port of call is "apt-get install libwhatever-dev". Building C/C++ libraries from upstream sources is considered a last resort. Whereas for rust users, noone seems to build or distribute binary libraries and the done thing is to use cargo which automatically downloads and builds the libraries your project needs. You have to actively go out of your way to make cargo use rust libraries from Debian rather than those from crates.io Upstream gnome developers may use flatpak, but I think upstream gnome developers are a small subset of the people building stuff against gtk.
Bug#983003: ITP: janet -- Dynamic language and bytecode VM
Package: wnpp Severity: wishlist Owner: "Bradford D. Boyle" X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: janet Version : 1.15.2 Upstream Author : Calvin Rose * URL : https://janet-lang.org/ * License : MIT Programming Lang: C Description : Dynamic language and bytecode VM Janet is a functional and imperative programming language and bytecode interpreter. It is a lisp-like language, but lists are replaced by other data structures (arrays, tables (hash table), struct (immutable hash table), tuples). The language also supports bridging to native code written in C, meta-programming with macros, and bytecode assembly. There is a REPL for trying out the language, as well as the ability to run script files. This client program is separate from the core runtime, so Janet can be embedded in other programs. Try Janet in your browser at https://janet-lang.org.
