Bug#764439: ITP: jackson-dataformat-cbor -- Jackson data format module for "Concise Binary Object Representation"

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: jackson-dataformat-cbor
  Version : 2.4.3
  Upstream Author : FasterXML, LLC
* URL or Web page : https://github.com/FasterXML/jackson-dataformat-cbor
* License : Apache-2.0
  Description : Jackson data format module for RfC7049 Concise Binary 
Object Representation


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvezf5p7@msgid.hilluzination.de

Re: Enlightenment DR19 - Maintainers?!

[Paul Tagliamonte]

On Wed, Oct 08, 2014 at 12:26:07AM -0300, Martinx - ジェームズ wrote:
>Hey guys!

And gals!

>I'm wondering here... Where are the E19 packages for Debian?!     :-P

You tell us!

I assume you're related to the recent reddit thread? If so, hi! Welcome!
If not, also hi! Welcome!

I'd suggest contacting the maintainers of e17 and seeing if they want to
work with you. There's also an Alioth group, I think!

[snip]

>Can't wait to try E-Wayland-Only!    =D

Sounds awesome!

>Cheers!
>Thiago
> 
> References
> 
>Visible links
>1. https://gist.github.com/tmartinx/86adc8f33b12f163028b#file-nineteen-2-sh
>2. 
> https://launchpad.net/~niko2040/+archive/ubuntu/e19?field.series_filter=trusty

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Enlightenment DR19 - Maintainers?!

[Martinx - ジェームズ]

Hey guys!

I'm wondering here... Where are the E19 packages for Debian?! :-P

I'm so tired of Gnome, Unity, KDE, XFCE, LXDE, Network Manager... hh!!
  :-)

So, why not make a *near to perfect* E19 packages for Debian (or Ubuntu)?
Using Econnman by default, Terminology and etc... ???

Right now, I'm using E19 compiled by hand, using my script (forked):

https://gist.github.com/tmartinx/86adc8f33b12f163028b#file-nineteen-2-sh

Also, I tried this PPA:
https://launchpad.net/~niko2040/+archive/ubuntu/e19?field.series_filter=trusty
but, it is too different from "original" Debian packages...

Lets make a Debian spin based on E19?!

Can't wait to try E-Wayland-Only!=D

Cheers!
Thiago

Re: Fwd: bash exorcism experiment ('bug' 762923 & 763012)

[Charles Plessy]

Le Tue, Oct 07, 2014 at 06:07:19PM +0200, Thorsten Glaser a écrit :
> 
> I deliberately used an extremely few insulting word for this
> but I don’t know how to else express it. And I do not believe
> in staying quiet if it can’t be politely expressed, because,
> let’s face it, the real world *is* full of shit, no matter
> where you look at.

So basically, you are using the passive-aggressive argument that you did your
best regarding avoiding insults, but it was unavoidable because the other
person really deserves insults.  And you do this about a decision taken in
2009, from which you had ample time to get over.

On this mailing list, you went as far as calling for murder, and regularly
insulting others.

I hope that next time you will get at the very least banned from posting on
this list for a few weeks.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007221631.ga1...@falafel.plessy.net

Re: Bug#720517: configuration files, ownership and dpkg-statoverride

[Henrique de Moraes Holschuh]

On Tue, 07 Oct 2014, Paul Gevers wrote:
> I am trying to come up with a patch against dpkg-statoverride that sets
> the ownership and permissions upon creation, but not upon updates.

This really doesn't look like a good idea.  In fact, it may well introduce
very confusing and likely dangerous behavior.

Anyway, are you sure dpkg-statoverride is the correct tool for your usecase
in the first place?

If you want to set ownership and permisions upon creation but not on
updates, this is should not be a job for the statoverride database.  The
debconf database or an ucf-managed config file under /etc somewhere seems
much better suited to store information only to be used at creation time, at
least in the general case.

The dpkg-statoverride database is in the _job_ of *clobbering* permission
and ownership information of filesystem objects, and it is very security
sensitive.

It is not there only to handle local customization, either: it is an
essential component of the internals of the debian packaging system when
dealing with security-sensitive filesystem objects that need to be created
or replaced while a package is unpacked.  You often need to interact with
the statoverride database in preinst, so that files will be created/replaced
atomically by dpkg with the already correct ownership and permission
information.

This logic applies to anything that uses it.  When something is registered
through dpkg-statoverride, it must be managed through dpkg-statoverride.
Directly changing those permissions in the filesystem is *unsupported* in
the sense that they are _expected_ to be clobbered the next time that file
is modified by the packaging system (and that includes maintainer scripts).

I really don't think it is wise to mess with this basic assumption.  If it
is invalid for your usecase, it most likely means you are using the wrong
tool for the job.

BTW: the statoverride databased has to be queried by dpkg for every
filesystem object it has to create/replace while unpacking _any_ package.


Anyway, if you're still going to use dpkg-statoverride anywhere the local
admin might rightfully expect permission/ownership changes to stick, I
suggest you seriously consider taking a heavy-handed approach to ensure the
local admins *know* they have to go through dpkg-statoverride to change the
permissions and ownership information of those filesystem objects.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007212301.gb3...@khazad-dum.debian.net

Re: Fwd: bash exorcism experiment ('bug' 762923 & 763012)

[Matthias Urlichs]

Hi,

Adam Borowski:
> > The only acceptable concrete value for 'extremely few' is Zero.
> 
> I'd say losing patience is quite understandable in this case

Probably. However, the context of this thread was not at all about a
maintainer who refused to apply a perfectly sensible patch. Getting
confronted with language like that, out of the blue, is no longer
something I'm willing to accept here.

A decade or so ago, this kind of thing was regarded as normal on our
mailing lists. We mostly-succeeded in civilizing the place, and frankly I
like them much better that way.

Slippery slope, and all that.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007200909.gf3...@smurf.noris.de

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Thorsten Glaser]

On Tue, 7 Oct 2014, Adam Borowski wrote:

> change your /bin/sh), 2. being (then) a violation of a "must" clause of
> the policy.

To be fair: my bug wasn’t about -a and -o, but about the printf builtin
which Policy is silent about. Some shells do have a builtin printf,
most don’t. printf(1) lives in /usr/bin, and Md’s init script set the
$PATH explicitly to /bin:/sbin yet still used printf(1), which, for a
POSIX sh script, is probably sensible anyway. He “just” barricaded all
three or four ways I could come up to fix this for the users.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410072133250.9...@tglase.lan.tarent.de

Re: Fwd: bash exorcism experiment ('bug' 762923 & 763012)

[Adam Borowski]

On Tue, Oct 07, 2014 at 07:41:30PM +0200, Matthias Urlichs wrote:
> Thorsten Glaser:
> > I deliberately used an extremely few insulting word for this
> 
> You should have deliberated a bit more, then.
> 
> The only acceptable concrete value for 'extremely few' is Zero.

I'd say losing patience is quite understandable in this case: tg took his
time to investigate a bug, provided a patch yet had it rudely ignored,
despite 1. the bug having nasty effects (unbootable system if you try to
change your /bin/sh), 2. being (then) a violation of a "must" clause of
the policy.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007193038.ga19...@angband.pl

Bug#764391: ITP: usbrelay -- USB HID relay driver

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 

* Package name: usbrelay
  Version : 0.0+git9b40688e
  Upstream Author : darrylb123
* URL : https://github.com/darrylb123/usbrelay
* License : to be clarified
  Programming Lang: C
  Description : USB HID relay driver

a small utility to control USB HID based relays that can be used for home
automation or other switching needs. The devices are available from several
sources and are able to handle up to 10A 250VAC.

An example application are USB controlable power switches. I use such a
switch to control the power supply of an external hard disk drive for backup
purposes.

I filed a ticket in upstreams bugtracker to clarify the licensing situation
[1].

[1] https://github.com/darrylb123/usbrelay/issues/6


-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://portfolio.debian.net/ - http://people.debian.org/~jandd/


signature.asc
Description: Digital signature

Re: Bug#720517: configuration files, ownership and dpkg-statoverride

[Paul Gevers]

On 07-10-14 15:40, Ian Jackson wrote:
> Also I don't see in your references an explanation from anyone as to
> why dbconfig-common does this.

I you mean with "why": "why is it implemented this way" than that is
exactly the question that I am asking myself looking at the code, if you
mean "why does dbconfig-common change the ownership of cactis
configuration file" than the answer is that you can tell dbconfig-common
in your maintainer scripts what the (I expected initial) ownership
should be. dbconfig-common than sets the ownership on every update of
the package where it is called, except when dpkg-statoverride is set.

I am trying to come up with a patch against dpkg-statoverride that sets
the ownership and permissions upon creation, but not upon updates.

Paul




signature.asc
Description: OpenPGP digital signature

Re: Weak c++ symbols refresher needed

[Bastian Blank]

On Tue, Oct 07, 2014 at 04:23:54PM +0800, Chow Loong Jin wrote:
> On Tue, Oct 07, 2014 at 09:37:48AM +0200, Mathieu Malaterre wrote:
> > I am starring at bug #758572. Basically OP reports that `cmake` is
> > underlinked, which is a serious issue as per policy. However when
> > reading the details it appears that this is a c++ weak symbol (AFAIK
> > no weak default definition is available). This weak symbol is
> > generated by default by gcc when using part of the STL (See
> > #758572#13).

No, he shows that using a different libcurl makes ld.so barf.  He
provides no evidence that the weak symbol is the reason for this.

> > Could someone please remind me in which case weak symbols (no weak
> > default definition) can trigger an undefined behavior at runtime ?
> I think UB is only triggered if something attempts to use the symbol. Is 
> cmake pulling in
> another library that uses libpthread but doesn't link it in?

No, this is perfectly valid.  Weak symbols are initialized to zero if no
definition is found.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007174834.ga21...@mail.waldi.eu.org

Re: Fwd: bash exorcism experiment ('bug' 762923 & 763012)

[Matthias Urlichs]

Hi,

Thorsten Glaser:
> I deliberately used an extremely few insulting word for this

You should have deliberated a bit more, then.

The only acceptable concrete value for 'extremely few' is Zero.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007174130.gd3...@smurf.noris.de

Re: Your behaviour on Debian lists

[Ondřej Surý]

On Tue, Oct 7, 2014, at 18:00, Cyril Brulebois wrote:
> Thorsten Glaser  (2014-10-07):
> > Yeah, but Md is an arsehole anyway and requires printf to be
> > a /bin/sh builtin instead of just adding /usr/bin to $PATH,
> > especially now that the initrd mounts /usr already anyway,
> > and CTTE decided to rather offend me than Md because he is
> > maintainer of the more important packages, or those where
> > it’s hard to find someone else for.
> 
> I can't believe I'm reading this.
> 
> Such a toxic behaviour is very much not welcome on Debian lists, or
> anywhere within the Debian project.
> 
> Please apologize and never do that again.
> 
> But since that isn't the first time (see May 2014), and since you don't
> seem to care about your fellow developers, it might be worth considering
> leaving the project entirely.

As I have witnessed several such behaviour myself on the debian lists,
and tg is only person I do have in my killfile, I am strongly seconding
this.

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412702339.4184912.176218889.3758c...@webmail.messagingengine.com

Fwd: bash exorcism experiment ('bug' 762923 & 763012)

[Thorsten Glaser]

Forwarding a bit of my answer on this. I don’t know what to
think about how this criticism immediately raises responses
like the two I already got, yet the other person in question
is allowed to disrespect his fellow DDs and just ignore the
fixes for real-world, although minority, problems.

I deliberately used an extremely few insulting word for this
but I don’t know how to else express it. And I do not believe
in staying quiet if it can’t be politely expressed, because,
let’s face it, the real world *is* full of shit, no matter
where you look at.

-- Forwarded message --
[…]

This is not “vitriol”, if I understand that word right, but a
somewhat coloured but nevertheless true description of facts.
I have been repeatedly backed up, in private, about this issue
by other DDs, but Md’s decision to actively break other shells
even when a workaround or even proper fix is pointed out to him
is destructive yet CTTE-backed. There are no words to describe
this…

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410071803380.23...@tglase.lan.tarent.de

Your behaviour on Debian lists

[Cyril Brulebois]

Thorsten Glaser  (2014-10-07):
> Yeah, but Md is an arsehole anyway and requires printf to be
> a /bin/sh builtin instead of just adding /usr/bin to $PATH,
> especially now that the initrd mounts /usr already anyway,
> and CTTE decided to rather offend me than Md because he is
> maintainer of the more important packages, or those where
> it’s hard to find someone else for.

I can't believe I'm reading this.

Such a toxic behaviour is very much not welcome on Debian lists, or
anywhere within the Debian project.

Please apologize and never do that again.

But since that isn't the first time (see May 2014), and since you don't
seem to care about your fellow developers, it might be worth considering
leaving the project entirely.

KiBi.


signature.asc
Description: Digital signature

Re: dgit and upstream git repos

[Daniel Pimentel (d4n1)]

2014-10-07 12:01 GMT-03:00 Matthias Urlichs :

> Hi,
>
> Ian Jackson:
> > On `source code': I think everyone should have the same definition of
> > `source code' for git as for tarballs.
> >
> I beg to differ. Not in principle, but because tarballs and git trees
> target different groups of users.
>
> I expect people who use my git trees to have a reasonably-recent system
> which has a reasonably-current copy of autotools installed.
>
> I expect no such thing from people who download a tarball onto CentOS 5
> (or Solaris for that matter). They want "sh ./configure && make" to
> work. (So do I, if/when I download a tarball, for that matter.)
>
> The source code, as in "the thing I work with when I want to change
> the behavior of the program", is the git archive. It's not the tarball,
> and it's empharically not anything produced by autotools.
> (I really really don't like cluttering git trees with non-source.)
>
> I no longer regard tarballs as "source", strictly speaking. They're an
> inconvenient (to me) way to package a bunch of files that can be used
> to produce+install an executable.
>
> --
> -- Matthias Urlichs
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20141007150126.gb3...@smurf.noris.de
>
>


-- 
Msc. Daniel Pimentel (d4n1 )

Re: dgit and upstream git repos

[Russ Allbery]

Ian Jackson  writes:

> On `source code': I think everyone should have the same definition of
> `source code' for git as for tarballs.

I understand why you feel this way, particularly given the tools that
you're working on, but this is not something I'm going to change as
upstream.  Git does not contain generated files, and the tarball release
does, because those two things are for different audiences.  Including the
generated files in Git generates a bunch of churn and irritating problems
on branch merges for no real gain for developers.  Not including them
makes it impossible for less sophisticated users to deploy my software
from source on older systems on systems that do not have Autoconf and
friends installed for whatever reason.  Both of those are real use cases I
regularly encounter, and having different contents in Git and the release
tarball solves both use cases quite well, with only a minor and
easily-automated inconvenience for packaging tools.

I say this not to pick a fight, since it's totally okay with me that you
feel differently, but to be clear that, regardless of preferences, the
reality that we'll have to deal with is that upstreams are not going to
follow this principle.  I know I'm not alone in putting my foot down on
this point.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tqjew96@hope.eyrie.org

Re: Bug#757941: static linking: alternatives for glibc?

[Matthias Urlichs]

Hi,

Julian Taylor:
> this is already the case with regular static linking, you don't need LTO
> to remove unused code, the compiler only uses those objects from that
> archive that are required to resolve all symbols.
> 
… remove _some_ unused code. Lots of code the linker pulls in from gcc will
never be called. For instance, it doesn't _know_ that none of your printf
statements contain '%f', so it adds the heap of code required to print
floats regardless.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007151707.gc3...@smurf.noris.de

Re: dgit and upstream git repos

[Matthias Urlichs]

Hi,

Ian Jackson:
> On `source code': I think everyone should have the same definition of
> `source code' for git as for tarballs.
> 
I beg to differ. Not in principle, but because tarballs and git trees
target different groups of users.

I expect people who use my git trees to have a reasonably-recent system
which has a reasonably-current copy of autotools installed.

I expect no such thing from people who download a tarball onto CentOS 5
(or Solaris for that matter). They want "sh ./configure && make" to
work. (So do I, if/when I download a tarball, for that matter.)

The source code, as in "the thing I work with when I want to change
the behavior of the program", is the git archive. It's not the tarball,
and it's empharically not anything produced by autotools.
(I really really don't like cluttering git trees with non-source.)

I no longer regard tarballs as "source", strictly speaking. They're an
inconvenient (to me) way to package a bunch of files that can be used
to produce+install an executable.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007150126.gb3...@smurf.noris.de

Re: configuration files, ownership and dpkg-statoverride

[Ian Jackson]

Paul Gevers writes ("configuration files, ownership and dpkg-statoverride"):
> I am looking into dbconfig-common RC bug 720517 [1] and I was wondering
> what the general idea is of maintainer scripts changing the permissions
> and/or owners of configuration files and the use of dpkg-statoverride.

The user should not be expected or required to use dpkg-statoverride
on configuration files (whether they are dpkg-managed conffiles or
maintainers-script-managed).  chmod/chown should be sufficient.

>  I myself find it unacceptable that updating a package changes the
> permissions/owners of a configuration file without asking, even when
> I have not documented that fact with dpkg-statoverride. At least
> that is how I read policy 10.7.3 [2].

I think you are right.  But I don't see anyone disputing this.
Also I don't see in your references an explanation from anyone as to
why dbconfig-common does this.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21555.60773.431402.870...@chiark.greenend.org.uk

Re: bash exorcism experiment ('bug' 762923 & 763012)

[The Wanderer]

On 10/07/2014 at 02:39 AM, Russell Stuart wrote:

> On Fri, 2014-10-03 at 09:20 -0700, Russ Allbery wrote:

>> Oh!  I didn't realize or internalize that you were proposing
>> switching the default shell to posh from dash.  Yes, that would
>> certainly improve our compliance with Policy considerably.
> 
> It's attractive because makes Policy more relevant - but only because
> of that.  Now that I think about it, switching pbuilder to posh would
> be almost as good.  Any additional pain would not be worth the
> effort.

Speaking as an uninvolved but interested observer, I though this
(switching the shell people use to build and test their packages, and
nothing else) was what you were proposing in the first place.

-- 
   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


0x3428326B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Neil McGovern]

On Tue, Oct 07, 2014 at 03:03:05PM +0200, Thorsten Glaser wrote:
> Yeah, but Md is an arsehole anyway and requires printf to be
> a /bin/sh builtin instead of just adding /usr/bin to $PATH,
> especially now that the initrd mounts /usr already anyway,
> and CTTE decided to rather offend me than Md because he is
> maintainer of the more important packages, or those where
> it’s hard to find someone else for.
> 

Thorsten,

Could you please keep your tone more civil? Personal attacks on fellow
project members and conspiracy theories does nothing to further your
technical arguments - in fact it makes me more likely to dismiss any
valid point you may have.

Neil
-- 


signature.asc
Description: Digital signature

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Thorsten Glaser]

On Sat, 4 Oct 2014, Russ Allbery wrote:

> >> If we were to decide that #309415 should be fixed in policy (and hence
> >> posh), then it should be done by requiring support for the obsolescent

The problems with posh and dash are also the sheer number of bugs
in corner cases, which the more actively developed shells fix.

posh inherited all bugs from pdksh which I fixed in mksh, partially
by rewriting the parser… so it had to be restarted from newer code.

dash, well, just ugh.

tglase@tglase:~ $ cat x
a='space divded  argument
here'
IFS=\  ; set -- $a
IFS= ; q="$*" ; nq=$*
printf '<%s>\n' "$*" $* "$q" "$nq"
[ "$q" = "$nq" ] && echo =true || echo =false
tglase@tglase:~ $ dash x




=true
tglase@tglase:~ $ ksh93 x






=true

> > It's already fixed:
>
> > * ‘test’, if implemented as a shell built-in, must support ‘-a’ and ‘-o’
> > as binary logical operators.
>
> Yeah, that's been there for a while.  They were too widely used, so
> although they're really confusing, we decided not to pick that fight.

Yeah, but Md is an arsehole anyway and requires printf to be
a /bin/sh builtin instead of just adding /usr/bin to $PATH,
especially now that the initrd mounts /usr already anyway,
and CTTE decided to rather offend me than Md because he is
maintainer of the more important packages, or those where
it’s hard to find someone else for.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410071459300.23...@tglase.lan.tarent.de

Re: dgit and upstream git repos

[Ian Jackson]

Enrico Zini writes ("dgit and upstream git repos"):
> This is my scenario: I'm the upstream developer, I have an existing git
> repo with all the project history, and I'd like to be able to git push
> to debian using dgit.
> 
> I ran "dgit fetch", I ran "git checkout -b dgit/sid dgit/dgit/sid" and
> all was fine.
> 
> When I had my new upstream version ready, however, and tried to merge it
> into the dgit branch, I realised that my development branch did not
> contain ./configure, Makefile.in and other autogenerated stuff, while
> the dgit branch of course did.

Right.

Since dgit is a way of editing the Debian archive using git, you
obviously have to have the actual complete contents of the Debian
package in your dgit git trees.

It appears that you want the Debian package to contain a different set
of files to the upstream git history.  I think this is a bad idea and
I have a rant about the meaning of `source code' which I will write at
the end of this message.

But nevertheless, doing this with dgit is easy.

> If anyone is working in a similar scenario and has a handy workflow
> with dgit, can you please tell me how you do things?

I think you can do what you want like this:

  dgit fetch sid
  git checkout -b dgit/sid dgit/dgit/sid
 # equivalent to   git checkout dgit/sid   I think
  git reset --hard upstream
  git merge -s ours dgit/dgit/sid
  git clean -xdff
  ./autogen.sh
  git add .
  git commit -sm 'Add autogenerated files'
  ed debian/changelog
  dgit push

This assumes that your `upstream' branch has debian/ files.  If it
doesn't then you will need to do something more complicated.  One way
is this:

  git checkout -b dgit/sid dgit/dgit/sid
  git merge -s ours upstream-tag-corresponding-to-this-debian-version
  git merge upstream
  ./autogen.sh
  git commit -asm 'Update autogenerated files'



On `source code': I think everyone should have the same definition of
`source code' for git as for tarballs.

That means either:

 1. configure, Makefile.in, etc. are supplied in both.  If you edit
configure.ac, you run autogen.sh and commit the result.  This
works perfectly fine and I work this way with many of my own
projects.  In the Xen project (which I work on during my day job)
we even commit flex and bison output because some of our
contributors are using old distro releases with prehistoric
versions.

A disadvantage is that sometimes you see a conflict in configure
(or another autogenerated file), but you can always solve them
with ./autogen.sh so it's never a problem.  And you see diffs to
configure etc. in your VCS history.

The advantage is that people on deficient operating systems, who
may not have the necessary version of autoconf or whatever, can
still build your package from git.  This is quite important if you
want to be able to take bug reports and code contributions from
such people!  You can hardly say `pls try latest tip' if they
can't build it.

 2. None of the autogenerated files are in git or the tarball.  The
INSTALL file doesn't say `./configure && make && make install';
it says `./autogen.sh && ./configure ...'.  debian/rules always
runs ./autogen.sh.

The advantage is that everyone is always building the package
fully from the ultimate source code.  The disadvantage is that
your build-dependencies now always include the latest and greatest
autoconf or automake or whatever, or you have to delay using new
features in your build infrastructure until all your downstreams
and contributors have finally stopped using Centos 5.


Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21555.53935.131317.238...@chiark.greenend.org.uk

Bug#764325: ITP: ddate -- convert Gregorian dates to Discordian dates

[Sebastian Schmidt]

Package: wnpp
Severity: wishlist
Owner: Sebastian Schmidt 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: ddate
  Version : 0.2.2
  Upstream Author : Jeremy Johnson 
* URL : https://github.com/bo0ts/ddate
* License : Public Domain
  Programming Lang: C
  Description : convert Gregorian dates to Discordian dates

Displays the Discordian date of a given date. The Discordian calendar
was made popular by the "Illuminatus!" trilogy by Robert Shea and Robert
Anton Wilson.

ddate is no longer included in util-linux 2.25 so some fellow pope
decided to fork the code on github.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVDOtdvhx3EthBlqjAQhNtRAAvqXRRXSqCKvlx/UXQFipeb/vViW1AT2e
RQWK8JL9p3frEZl7KZfWVrPoJVpvmV3jr5iO2Ui9gRZBNPpvHS1dQiizZFGUSBt2
/Qv2zff7ogWkK+Qh/cGupT2RaW7rNJqs8jm8d/jLCfCLhhjrWjrC+UxIpwvIxhEd
AWsLOnrUWg8M15czVtXzNxuadKCp3grojFEpVNStletrC5b60v3Kl02+qW1Usf/g
YyrCpL0hGVITY2PagrvcpUN3pZAVKRppKYMiSRh4dvugLaFqLi+k2A3/j/qYg89X
BsG8WIoe50YsV0PXTV8/3KiRhC5oj/xQ79/WMQ8YW+cqoKPiUHzxcYgP8xiQpiB4
Ox7sBDQI9k0Pi6hSfUJUqTXuYVFupDonswtkMLD9ZQgLRUeT1vXgJ0CjAlAtjces
sVU01SK0BmCPVtnYStq4gIrHa4faY4xWHoOR8ktlFoErPw0CK0XL2AjEmDfk7UY7
MXBiu5btBcx6ZiHZCPxOnCQ9xFtVFX74dHsgA13XTjHjFaGgHsMFny68H2hAwFW/
13t1xA9kHcGnWN+FzgP2Jv558pXvREJlQwZPbQqY2axeCHb//6pSas4UhHgr7T5v
To2+i2+PoaITbi1j1PdIvl8AV/1lC+ygw4aanYP7MIj74XmrfuMbp5TC5xVpggy/
Ih7VzpLUcsc=
=k5mj
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141007090811.28363.33185.report...@moniac.lan.yath.de

Re: Weak c++ symbols refresher needed

[Chow Loong Jin]

On Tue, Oct 07, 2014 at 09:37:48AM +0200, Mathieu Malaterre wrote:
> Hi,
> 
> I am starring at bug #758572. Basically OP reports that `cmake` is
> underlinked, which is a serious issue as per policy. However when
> reading the details it appears that this is a c++ weak symbol (AFAIK
> no weak default definition is available). This weak symbol is
> generated by default by gcc when using part of the STL (See
> #758572#13).
> 
> So I would be tempted to simply close the bug as invalid, since weak
> symbol without default definition should not be an issue. However OP
> reports that it makes `cmake` fails using a custom `libcurl`.
> 
> Could someone please remind me in which case weak symbols (no weak
> default definition) can trigger an undefined behavior at runtime ?

I think UB is only triggered if something attempts to use the symbol. Is cmake 
pulling in
another library that uses libpthread but doesn't link it in?

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Weak c++ symbols refresher needed

[Mathieu Malaterre]

Hi,

I am starring at bug #758572. Basically OP reports that `cmake` is
underlinked, which is a serious issue as per policy. However when
reading the details it appears that this is a c++ weak symbol (AFAIK
no weak default definition is available). This weak symbol is
generated by default by gcc when using part of the STL (See
#758572#13).

So I would be tempted to simply close the bug as invalid, since weak
symbol without default definition should not be an issue. However OP
reports that it makes `cmake` fails using a custom `libcurl`.

Could someone please remind me in which case weak symbols (no weak
default definition) can trigger an undefined behavior at runtime ?

Thanks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUszr9uQ-Ab9O8_GHGFkYpf==7iubeugfwa10xpsquit...@mail.gmail.com

Re: Bug#757941: static linking: alternatives for glibc?

[Julian Taylor]

On 07.10.2014 08:07, Paul Wise wrote:
> On Tue, Oct 7, 2014 at 1:58 PM, Michael Tokarev wrote:
> 
>> apps becomes huge in size
> 
> I wonder if LTO would help with the size issues, theoretically all the
> code from the static glibc that isn't used by busybox-static would be
> stripped out of the resulting binaries.
> 

this is already the case with regular static linking, you don't need LTO
to remove unused code, the compiler only uses those objects from that
archive that are required to resolve all symbols.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543397bc.6020...@googlemail.com