Bug#991194: ITP: opentracing-c-wrapper -- C wrapper for the C++ impl of the OpenTracing API

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-devel@lists.debian.org, ssg...@debian.org

* Package name: opentracing-c-wrapper
  Version : 1.1.0
  Upstream Author : HAProxy Technologies
* URL : https://github.com/haproxytech/opentracing-c-wrapper/
* License : Apache-2.0
  Programming Lang: C/C++
  Description : C wrapper for the C++ impl of the OpenTracing API

OpenTracing C Wrapper library was created due to the need to use distributed
tracing within C programs.

The OpenTracing project (https://opentracing.io/) has published a
C-language implementation on https://github.com/opentracing/opentracing-c
but that implementation is incomplete, with the last update on Jun
27th 2018

This library takes inspiration from the header files in that project but
implements the proposed functionality fully by wrapping the functional
C++ library.

This is a dependency of building haproxy with opentracing support.

Bug#991193: ITP: opentracing-cpp -- OpenTracing API for C++

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-devel@lists.debian.org, ssg...@debian.org

* Package name: opentracing-cpp
  Version : 1.6.0
  Upstream Author : The OpenTracing Authors
* URL : https://github.com/opentracing/opentracing-cpp/
* License : Apache-2.0
  Programming Lang: C++
  Description : OpenTracing API for C++

C++ implementation of the OpenTracing API. See http://opentracing.io for 
additional information.

This is being packaged as part of an effort to add opentracing support
to haproxy.

Bug#991191: ITP: catgirl -- TLS-only terminal IRC client

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: catgirl
  Version : 1.8
  Upstream Author : C. McEnroe 
* URL : https://git.causal.agency/catgirl/about/
* License : GPLv3+ plus OpenSSL exception
  Programming Lang: C
  Description : TLS-only terminal IRC client

A minimal terminal IRC client with tab completion, split scrolling, nick
colouring, topic diffing, and message filtering.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Debian Med videoconference tomorrow, Saturday 2021-07-17 18:00 UTC

[Andreas Tille]

Hi,

this is the call for the next video conference of the Debian Med team
that are an established means to organise the tasks inside our team.
We do these conferences twice per month on every

   2th  and  17th

of a month.  Usually it takes us only 15-20min depending what we are
talking about and how many people are joining.  The next meeting is
today 18:00 UTC
   
 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=20210717T18

The meeting is on the Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

These video meetings were started in the Debian Med Biohackathon.
The topic is what contributors have done in the past period and to
coordinate the work until the next meeting.

For those who are interested in hot topics we want to tackle, here
are some items:

  - Effort to package tensorflow and other ML software which is
used in several applications that are used to fight COVID-19.
The precondition bazel to package tensorflow was a direct
consequence of a Debian Med hackathon and it was even
acknowledged[1]

  - Package software that is used to fight COVID-19 which we are
listing in some spreadsheet[2].  It reaches from small tools
up to complex software packages.  There should be targets for
everybody who wants to join us.

  - General Debian Med issues not directly connected to COVID-19

  - Finally we should discuss how to start the next release cycle
since this is probably the last video conference before the
Debian 11 release.

Newcomers are always welcome.

Lets keep on the great work and see you today
 
   Andreas.

[1] https://blog.bazel.build/2021/03/04/bazel-debian-packaging.html
[2] 
https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=543782716

-- 
http://fam-tille.de

Re: Debian 11, system.map, DKMS

[Жора Волков]

>No normal kernel module requires tinkering with System.map.  Kernel
>modules use exported functions via normal linking and relocation.  This
>is what everyone uses.

Understood. How does one make a function export request?

>So if some module uses System.map, it wants to use not exported
>functions or violate the kernel license.  Function addresses are not
>even part of our ABI, so such modules are not even compatible between
>different builds of the kernel.  Sorry, but why should we support this?

>So you have a workaround.

I was hoping there was a way to avoid installing a package which weighs
several gigabytes...

Thanks!

Re: Debian 11, system.map, DKMS

[Bastian Blank]

Hi

On Fri, Jul 16, 2021 at 03:08:51PM +0200, Жора Волков wrote:
> A DKMS-built kernel module that I have on my system relies on system.map. A
> build script for the module parses that file in order to figure out
> addresses of certain functions.

No normal kernel module requires tinkering with System.map.  Kernel
modules use exported functions via normal linking and relocation.  This
is what everyone uses.

So if some module uses System.map, it wants to use not exported
functions or violate the kernel license.  Function addresses are not
even part of our ABI, so such modules are not even compatible between
different builds of the kernel.  Sorry, but why should we support this?

> Now, without that file in Debian 11, there is simply no way for my
> DKMS-built module to find out the required function's address (unless I
> install that gargantuan debug package).

So you have a workaround.

Bastian

-- 
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

Debian 11, system.map, DKMS

[Жора Волков]

 Hello everyone,

A DKMS-built kernel module that I have on my system relies on system.map. A
build script for the module parses that file in order to figure out
addresses of certain functions.

Now, without that file in Debian 11, there is simply no way for my
DKMS-built module to find out the required function's address (unless I
install that gargantuan debug package).

Any ideas how I could get things to work the way they worked in Debian 10?

Thanks!

Re: debian-devel-digest Digest V2021 #237

[mrplumbo]

Unsubscribe

On Fri, Jul 16, 2021 at 1:21 AM,  
wrote:

> Empty Message

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Magissia]

In this case, this page should be updated to reflect the fact it is not
broken.

https://wiki.debian.org/Teams/Dpkg/MergedUsr

Nol'

Le jeudi 15 juillet 2021 à 10:13 +0100, Luca Boccassi a écrit :
> On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > > Sean Whitton dixit:
> > > > * #978636 move to merged-usr-only?
> > > > 
> > > >  We were asked to decide whether or not Debian 'bookworm'
> > > > should
> > > >  continue to support systems which are not using the merged-usr
> > > >  filesystem layout.  We decided that support should not
> > > > continue beyond
> > > >  Debian 'bullseye'.
> > > 
> > > What? WHAT? ＷＨＡＴ？
> > > 
> > > >  The decision is captured here:
> > > >  
> > > 
> > > No reason provided either. This stinks. I’m v̲e̲r̲y̲
> > > disappointed.
> > > Debian is becoming untenable. Years ago, I had hoped it won’t.
> > 
> > I've been meaning to send a note about this for some time now, but
> > as I feel it keeps getting ignored, it always seems a bit
> > pointless.
> > 
> > But in any case, given that merged-usr-via-aliased-dirs is not
> > really
> > supported by dpkg anyway, it is broken by design [B], I have no
> > intention whatsoever to break any of my systems with such layout
> > going
> > forward, I'm thus planning to spend any necessary volunteer time
> > implementing any fix, workaround or solution required to avoid
> > having
> > to use it, in detriment of other Debian volunteer time. I already
> > started some time ago with dpkg-fsys-usrunmess(8), present already
> > in
> > the upcoming bullseye release.
> > 
> > [B] <
> > https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
> > >
> > 
> > Thanks,
> > Guillem
> 
> Hi,
> 
> As it has been said and written many times already, in reality this
> is
> not broken by design at all and in fact it is the only successful
> strategy that has been deployed by other distros - it's what is being
> called merged-usr-via-moves-and-symlink-farms that is broken. We can
> say this with certainty because both approaches have been tried, so
> there's actual real-world data to look at. Just go look at the
> absolute
> mess that Suse got themselves into by following that solution - a 10-
> years-long massive half-done-never-finished headache that took an
> inordinate amount of work to back out of, and move to the actual
> working solution that everybody else are using - merged-usr-via-
> aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple
> transition using merged-usr-via-aliased-dirs, and that was the end of
> it.
> 
> Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not
> suffer from. So what? It is perfectly normal as it's software and all
> softwares have bugs. They could be fixed, worked around, or ignored,
> like all other bugs.
> 

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Thomas Goirand]

On 7/16/21 10:09 AM, Thomas Goirand wrote:
> On 7/14/21 9:54 PM, Thorsten Glaser wrote:
>> Sean Whitton dixit:
>>
>>> * #978636 move to merged-usr-only?
>>>
>>>  We were asked to decide whether or not Debian 'bookworm' should
>>>  continue to support systems which are not using the merged-usr
>>>  filesystem layout.  We decided that support should not continue beyond
>>>  Debian 'bullseye'.
>>
>> What? WHAT? ＷＨＡＴ？
>>
>>>  The decision is captured here:
>>>  
>>
>> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
>> Debian is becoming untenable. Years ago, I had hoped it won’t.
>>
>> bye,
>> //mirabilos
> 
> Hi Thorsten,
> 
> Sent privately, I hope you don't mind.

It was sent to the list, never mind, there's nothing private here, just
a call to be more constructive...

Cheers,

Thomas Goirand (zigo)

Re: merged /usr considered harmful

[Pierre-Elliott Bécue]

Thorsten Glaser  writes:
>>But in any case, given that merged-usr-via-aliased-dirs is not really
>>supported by dpkg anyway, it is broken by design [B], I have no
>
> Time for another GR? Leaving Debian behind?

Threats of leaving are not fine and are just making any discussion
pointless.

I refuse (and I recommend no one accepts) to enter debate with someone
putting their involvment in the balance as a way to force their opinion
in.

--
PEB


signature.asc
Description: PGP signature

endless discussion considered harmful

[Philip Hands]

Thorsten Glaser  writes:

...
> I *really* don’t get why…
>
> ⓐ these things aren’t done in a derivative that’s *really* close
>   to Debian proper but can do all the funky new stuff, preserving
>   support for the old stuff in Debian itself, and…

This issue has been explored very thoroughly, so if you've not noticed
that happening then I suspect that you decided to mostly ignore it.

The TC ended up deciding this because it's perfectly possible for
reasonable people to agree on the facts, but weigh the importance of the
various implications of those facts and available options differently.

> Frankly, usrmerge is WORSE then what we had before, in all possible
> ways.

By saying that, in that way, you give the impression that you assume
that the honestly held opinions of a lot of your fellow developers are
wrong and/or stupid.

Even if you think that, saying it as part of your argument tends to
force people make a snap decision on which side of the argument more
fools are standing, and then to pick sides, which entrenches opinion,
and so is pretty counter-productive if your intention is to persuade.

Making these 'unagreeable' decisions is the reason we need a TC.

Sadly there are always going to be winners and losers in these cases,
otherwise they wouldn't make it to the TC. Deciding to do nothing is a
decision too.

Do you think the TC didn't take that job seriously enough?

Do you think the TC considered insufficient evidence?

Did you not submit your most persuasive evidence for some reason?

I would hope that you are at least willing to admit that opinions on
this subject can differ even when the facts are generally agreed.

Also, that while you might be upset that your opinion didn't align with
the decision made by the TC, that the people making that decision were
devoting their best efforts to doing what they hope will serve the
project well in the long run.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: merged /usr considered harmful

[The Wanderer]

On 2021-07-16 at 03:18, Marc Haber wrote:

> On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser
>  wrote:
>
>>Marc Haber dixit:
>>
>>>think we can afford an additional time sink at the moment. Please, get
>>
>>While that’s true…
> 
> You conveniently snipped the "I don't" which turns your quote into the
> opposite that I wanted to say.

No, he didn't; he reordered the quoted lines (moving this one ahead of
the rest), so that he could put this one line of his reply where it
would make the most sense relative to the rest of his reply, without
also having to adjust the within-each-line quoting etc.. The "I don't"
is in the first line which you yourself didn't quote.

The result was slightly confusing to me at first glance, but I figured
it out within a minute.

If you'd chosen to chide him for reordering lines in a way which
(presumably inadvertently) produced an initially-misleading result, that
would be one thing, but I don't think it's appropriate to accuse him of
snipping out context when he didn't do so.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Thomas Goirand]

On 7/14/21 9:54 PM, Thorsten Glaser wrote:
> Sean Whitton dixit:
> 
>> * #978636 move to merged-usr-only?
>>
>>  We were asked to decide whether or not Debian 'bookworm' should
>>  continue to support systems which are not using the merged-usr
>>  filesystem layout.  We decided that support should not continue beyond
>>  Debian 'bullseye'.
> 
> What? WHAT? ＷＨＡＴ？
> 
>>  The decision is captured here:
>>  
> 
> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> Debian is becoming untenable. Years ago, I had hoped it won’t.
> 
> bye,
> //mirabilos

Hi Thorsten,

Sent privately, I hope you don't mind.

I very much like you, and appreciate the work you're doing in Debian.
However, I would not like at all if this is the start of yet-another
drama in Debian. We had enough of this.

Instead of complaining about change, it'd be nice if instead, you were
embracing it, and tried to contribute fixes for the parts that you're
maintaining in Debian. I'm not asking you to be enthusiastic about
changes you don't like, but maybe you could at least tried to understand
others are trying to improve things, rather than destroying your work.

Merging binaries in /usr and getting rid of /bin and /sbin, at the end,
WILL be an improvement. Debian cannot be the last distro not doing the
move, I hope you understand that.

Also, I'm having a hard time understanding why moving binaries around
should just break any system, especially if we have workarounds, like
symlink and/or bind mounts or the like. If non-systemd setups are having
issues, please just fix them... The end result *will* be a better Debian.

Last thing, the discussion happened a long time ago, you had plenty of
time to react, especially before the TC voted. Reacting so late, with
such emotion is really uncalled for.

Cheers,

Thomas Goirand (zigo)

Re: merged /usr considered harmful

[Thomas Goirand]

On 7/15/21 5:08 AM, Thorsten Glaser wrote:
> Guillem Jover dixit:
> 
>> I've been meaning to send a note about this for some time now, but
>> as I feel it keeps getting ignored, it always seems a bit pointless.
> 
> Yeah, I saw this popping up multiple times in that bugreport ☹
> 
>> But in any case, given that merged-usr-via-aliased-dirs is not really
>> supported by dpkg anyway, it is broken by design [B], I have no
> 
> Time for another GR?

Please don't! This isn't funny...

Thomas

Re: merged /usr considered harmful

[Marc Haber]

On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser
 wrote:
>Marc Haber dixit:
>>think we can afford an additional time sink at the moment. Please, get
>
>While that’s true…

You conveniently snipped the "I don't" which turns your quote into the
opposite that I wanted to say.

Greetings
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