Bug#989370: closed by Chris Hofstaedtler (Re: Bug#989370: general: In bonding network configuration, hwaddress crashes networking service, fails to restart)

[Chris Hofstaedtler]

Control: reopen 989370
Control: reassign 989370 ifupdown

Reassigning to ifupdown, which is the package having the
/etc/network/interfaces conffile.

Chris

Processed: Re: Bug#989370 closed by Chris Hofstaedtler (Re: Bug#989370: general: In bonding network configuration, hwaddress crashes networking service, fails to restart)

[Debian Bug Tracking System]

Processing control commands:

> reopen 989370
Bug #989370 {Done: Chris Hofstaedtler } [general] general: In 
bonding network configuration, hwaddress crashes networking service, fails to 
restart
Bug reopened
Ignoring request to alter fixed versions of bug #989370 to the same values 
previously set
> reassign 989370 ifupdown
Bug #989370 [general] general: In bonding network configuration, hwaddress 
crashes networking service, fails to restart
Bug reassigned from package 'general' to 'ifupdown'.
Ignoring request to alter found versions of bug #989370 to the same values 
previously set
Ignoring request to alter fixed versions of bug #989370 to the same values 
previously set

-- 
989370: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989370
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#989468: ITP: node-zrender -- A lightweight graphic library

[Harish]

Package: wnpp
Severity: wishlist
Owner: harish 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-zrender
  Version : 5.1.0+dfsg1
  Upstream Author :  2017, Baidu
* URL : https://github.com/ecomfe/zrender#readme
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : "a lightweight graphic library which provides 2d 
draw for Apache ECharts".


zrender - A lightweight canvas library which providing 2d draw for ECharts.

ECharts is a powerful charting and visualization library offering an easy
way of adding intuitive, interactive, and highly customizable charts to 
your commercial products.


 this package is graphic library for 'Apache Echart.

Re: Seeking feedback on a meta package builder

[Helmut Grohne]

Hi Raphaël,

On Fri, Jun 04, 2021 at 08:42:23AM +0200, Raphael Hertzog wrote:
> I don't intend to restrict too much the number of "tasks" that I will
> accept in debusine, we can have both if it makes sense. Though I believe
> that this is an abstraction worth having at the debusine level without
> delegating that abstraction to "mdbp".

This is very sad. The whole point of me reaching out where was
specifically trying to avoid this kind of fragmentation and now you're
adding to it. While mdbp also is an implementation, it first and
foremost is an API and I'd hope that it would be generic enough to be
reused here. Long term, I'd hope that each build tool would provide
their own implementation of the mdbp API, but adding multiple competing
build abstraction APIs is not going to get us there. Build tool authors
will rightly refuse saying that people should agree on an API first.

Choice is nice, but fragmentation has a cost.

Of course, you can turn this around and say that I'm the one fragmenting
and I should be using the debusine abstraction. Unfortunately, I'd need
a time machine to get it from the future. Otherwise, I'd really do that.

> I tried to fix it based on your feedback in the ticket but it looks like
> it doesn't match your expectation. When I request a build for the "arm64"
> architecture, I want "arm64.deb" as output, that's defined by the "host
> architecture" right?

Correct.

> (In this context, I would not care if it's build by cross-compilation in
> an amd64 build chroot or if it's build natively in an arm64 chroot)

A different way to put this is to say that the build architecture does
not matter and is left unspecified.

> As I said, I don't want to tightly couple it, it's just the easiest and
> most useful first step for me.

I doubt this is true. You already learned the hard way that coming up
with an abstraction for just sbuild is difficult. Using an existing
abstraction saves you from a pile of thinking and quite certainly is
easier.

Helmut

Re: Seeking feedback on a meta package builder

[Helmut Grohne]

Hi Sean,

On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote:
> dgit wraps some of the existing tools.  While dgit is mainly for humans,
> one role it can have in automated toolchains is producing an ephemeral
> source package for the purpose of performing a build where the real
> input is a git tree.  dgit knows how to convert various forms of git
> tree into source packages and there are TODOs for some others.

While dgit does wrap build tools and thus could be a possible mdbp user,
dgit does so in a way that forwards the flexibility of those build tools
through dgit. As such, it has a subcommand for each implementation and
lets the user fiddle with the underlying implementation in the way they
want without providing any kind of abstraction. I'm vaguely convinced
that for dgit, this is best. An abstraction could be added as another
subcommand if desired, but does buy little in the end. After all, dgit
users tend to want tight control over the build and know their favourite
build tool well.

The intended audience for the abstraction on the other hand would be
performing many builds in a mechanical way.

Helmut

Figuring how to work with team-maintained packages on salsa

[Florian Weimer]

I want to add a few patches to this repository:

  

Surely there must be some tool support to help with that?  I know how
to do it manually (perhaps even involving quilt).  Has every Debian
developer their own script for that?  (It's like this in RPM land …)

Re: Figuring how to work with team-maintained packages on salsa

[Andrey Rahmatullin]

On Fri, Jun 04, 2021 at 07:43:59PM +0200, Florian Weimer wrote:
> I want to add a few patches to this repository:
> 
>   
> 
> Surely there must be some tool support to help with that? 
This doesn't seem to be related to "team-maintained" or "salsa". This
seems to be a question about working with packaging in git (and there is
no single answer as there no single workflow, so unless the workflow used
is clear from the repo structure or there are docs, your only option is to
ask the maintainer/the team) or even a generic question about adding
packages to an unpacked source package, in which case the usual answer is
quilt.

> I know how to do it manually (perhaps even involving quilt).  Has every
> Debian developer their own script for that?
Many maintainers use one of popular tools, like git-buildpackage, but even
for a single tool there is no single workflow. Others probably indeed have
their own scripts.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Figuring how to work with team-maintained packages on salsa

[Helmut Grohne]

On Fri, Jun 04, 2021 at 07:43:59PM +0200, Florian Weimer wrote:
> I want to add a few patches to this repository:
> 
>   
> 
> Surely there must be some tool support to help with that?  I know how
> to do it manually (perhaps even involving quilt).  Has every Debian
> developer their own script for that?  (It's like this in RPM land …)

There is no homogeneity on git repositories. The sad truth is that if
you want to work with arbitrary packages in a homogeneous way, it is
best to avoid git entirely and work with .debdiffs instead. Eventually,
dgit might solve this, but its adoption still is fairly low.

Most of the time we're in favour of choice, flexibility and diversity.
This is one of the areas where diversity kills productivity. We've
mostly realized that for packaging helpers and the majority of the
archive uses dh now. It'll take another decade for us to realize this on
the vcs level.

Raphaël tried to formalize this in
https://lists.debian.org/20140815141601.ga11...@x230-buxy.home.ouaza.com,
but consensus wasn't reached back then in 2014. He did a stab via DEP-14
starting at
https://lists.debian.org/2014212624.ga19...@home.ouaza.com, but that
wasn't released either. For his work on dgit, Ian Jackson started an
informal survey on git packaging workflows at
https://lists.debian.org/21933.9687.747175.762...@chiark.greenend.org.uk.
Sam Harmann continued the effort in 2019 with
https://lists.debian.org/tslh86j7hgt@suchdamage.org. The one thing
that we learned in all this is that there are only few things we agree
on and that everyone wants to keep using their workflow.

As someone who regularly does archive-wide work, I can tell that this
diversity is a barrier to contributing.

Helmut

Re: Figuring how to work with team-maintained packages on salsa

[Mechtilde]

Hello

I started to automate and to document my way to Debian packaging with
git-buildpackage.

You can find the German description under

people.debian.org/~mechtilde/Dokumentation

It is work in Progress

Some people starting to translate it into English

The source code is at salsa.debian.org/ddp-team/dpb

Kind regards

Mechtilde


Am 04.06.21 um 20:49 schrieb Helmut Grohne:
> On Fri, Jun 04, 2021 at 07:43:59PM +0200, Florian Weimer wrote:
>> I want to add a few patches to this repository:
>>
>>   
>>
>> Surely there must be some tool support to help with that?  I know how
>> to do it manually (perhaps even involving quilt).  Has every Debian
>> developer their own script for that?  (It's like this in RPM land …)
> 
> There is no homogeneity on git repositories. The sad truth is that if
> you want to work with arbitrary packages in a homogeneous way, it is
> best to avoid git entirely and work with .debdiffs instead. Eventually,
> dgit might solve this, but its adoption still is fairly low.
> 
> Most of the time we're in favour of choice, flexibility and diversity.
> This is one of the areas where diversity kills productivity. We've
> mostly realized that for packaging helpers and the majority of the
> archive uses dh now. It'll take another decade for us to realize this on
> the vcs level.
> 
> Raphaël tried to formalize this in
> https://lists.debian.org/20140815141601.ga11...@x230-buxy.home.ouaza.com,
> but consensus wasn't reached back then in 2014. He did a stab via DEP-14
> starting at
> https://lists.debian.org/2014212624.ga19...@home.ouaza.com, but that
> wasn't released either. For his work on dgit, Ian Jackson started an
> informal survey on git packaging workflows at
> https://lists.debian.org/21933.9687.747175.762...@chiark.greenend.org.uk.
> Sam Harmann continued the effort in 2019 with
> https://lists.debian.org/tslh86j7hgt@suchdamage.org. The one thing
> that we learned in all this is that there are only few things we agree
> on and that everyone wants to keep using their workflow.
> 
> As someone who regularly does archive-wide work, I can tell that this
> diversity is a barrier to contributing.
> 
> Helmut
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

perl necessary for debootstrap, why?

[RhineDevil]

I've looked up /usr/share/debootstrap/functions and I've seen some perl code
Can I know why perl is a requirement if pkgdetails.c is not found?
What does this code do exactly and why wasn't it translated to shell?


pgpGr5PTgqWTj.pgp
Description: Firma digitale OpenPGP

Bug#989478: ITP: agnostic-lizard -- best-effort portable code walker for Common Lisp

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-common-l...@lists.debian.org

* Package name: agnostic-lizard
  Version : 0~git20201010.1.fe3a737-1
  Upstream Author : Michael Raskin <38a93...@rambler.ru>
* URL : https://gitlab.common-lisp.net/mraskin/agnostic-lizard
* License : GPL-3+
  Programming Lang: Common Lisp
  Description : best-effort portable code walker for Common Lisp

See

Michael Raskin.  2017.  Writing a best-effort portable code walker
in Common Lisp.  In Proceedings of 10th European Lisp Symposium,
Vrije Universiteit Brussel, Belgium, April 2017 (ELS2017).
DOI: 10.5281/zenodo.3254669

I am packaging this as a new dependency of one of my other packages,
Consfigurator.  I intend to maintain this package under the umbrella of
the Common Lisp team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: How to commit a new architecture like RISC-V

[Paul Wise]

On Sat, May 22, 2021 at 3:24 AM Paul Wise wrote:

> The steps are essentially documented in the port template wiki page,
> but I have rewritten the page into some clearer text here.

The instructions I provided are now available on this wiki page, but
much improved with input from other folks, please review the wiki page
and proceed according to the steps listed there. Don't skip any steps
and don't proceed to any step before completing the steps before it.
The page may change based on input from others, so check for changes
to the page occasionally.

https://wiki.debian.org/PortsDocs/New

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

ARM architectures

[Polyna-Maude Racicot-Summerside]

Hi !
I'm looking for a ARM platform that can easily run Linux.
Support using terminal over serial port for booting (no need of a GPU).

I know about the Raspberry PI but the GPU drivers are not open source.
I don't really need a GPU, if I do need graphics then I could always go
with a X over Ethernet.

Something like a modern board with possibility to use USB.

Someone got idea ?

Not too expensive...
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989489: ITP: elementary-terminal -- Modern terminal emulator from elementary project

[Francisco M Neto]

Package: wnpp
Severity: wishlist
Owner: Francisco M Neto 
X-Debbugs-Cc: debian-devel@lists.debian.org, fmn...@fmneto.com

* Package name: elementary-terminal
  Version : 5.5.2
  Upstream Author : elementary, Inc 
* URL : https://elementary.io
* License : GPL-3
  Programming Lang: Vala
  Description : Modern terminal emulator from elementary project

Originally named Pantheon Terminal, this is the default terminal emulator
in elementary OS. It is designed to be set up with sane defaults and
requires minimal configuration, following elementary's Human Interface
Guidelines.

This is yet another terminal emulator, which provides good funcionality
with good integration into the current GTK theme and minimal
requirement for configuration. It offers tab support and integration
with the desktop.

This package is part of an effort (on my part) to package some
applications from elementary OS for Debian.

Re: ARM architectures

[Siji Sunny]

> Hi !
> I'm looking for a ARM platform that can easily run Linux.
> Support using terminal over serial port for booting (no need of a GPU).
>
> I know about the Raspberry PI but the GPU drivers are not open source.
> I don't really need a GPU, if I do need graphics then I could always go
> with a X over Ethernet.
>
> Something like a modern board with possibility to use USB.
>

Dear Polyna,

Below few options which you should explore -

   - BeagleBoard (Bone black, etc) - https://beagleboard.org/
   - Odroid - https://www.hardkernel.com/ . They having multiple boards
   which is powered by ARM processors
   - Marvel Expressobin - http://espressobin.net/
   - BananaPI - http://www.banana-pi.org/
   - 96boards Portal by Linaro - https://www.96boards.org/





>
> Someone got idea ?
>
> Not too expensive...
> --
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource development
>
>

-- 
Siji Sunny

Re: ARM architectures

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-05 1:52 a.m., Siji Sunny wrote:
> 
> Hi !
> I'm looking for a ARM platform that can easily run Linux.
> Support using terminal over serial port for booting (no need of a GPU).
> 
> I know about the Raspberry PI but the GPU drivers are not open source.
> I don't really need a GPU, if I do need graphics then I could always go
> with a X over Ethernet.
> 
> Something like a modern board with possibility to use USB.
> 
> 
> Dear Polyna,
> 
> Below few options which you should explore -
> 
>   * BeagleBoard (Bone black, etc) - https://beagleboard.org/
> 
>   * Odroid - https://www.hardkernel.com/  .
> They having multiple boards which is powered by ARM processors
>   * Marvel Expressobin - http://espressobin.net/ 
>   * BananaPI - http://www.banana-pi.org/ 
>   * 96boards Portal by Linaro - https://www.96boards.org/
> 
> 
Thanks for all those ideas. I've just clicked one link and I'm already
amazed by the great possibility of Odroid. I could even build my own
custom portable game machine :) Or portable Linux machine... Sometime
get code to compile is the hardest game ;-)

Thanks
> 
> 
>  
> 
> 
> Someone got idea ?
> 
> Not too expensive...
> -- 
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource development
> 
> 
> 
> -- 
> Siji Sunny

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature