[DNG] apt-file doesn't work (ascii/ceres)

[Yevgeny Kosarzhevsky]

Hello,

I find that apt-file is not showing any results for ascii/ceres repos.

~# apt-file update
Ign:1 http://dl.google.com/linux/chrome/deb stable
InRelease

Hit:2 http://packages.devuan.org/merged jessie
InRelease

Hit:3 http://auto.mirror.devuan.org/merged jessie-backports
InRelease

Hit:4 http://dl.google.com/linux/chrome/deb stable
Release

Hit:5 http://packages.devuan.org/merged jessie-updates
InRelease

Hit:6 http://auto.mirror.devuan.org/merged jessie-proposed-updates
InRelease

Hit:8 http://packages.devuan.org/merged ascii
InRelease

Hit:9 http://packages.devuan.org/merged ascii-updates
InRelease

Hit:10 http://packages.devuan.org/merged ceres
InRelease

Hit:11 https://dl.ring.cx/ring-nightly/debian_9 ring
InRelease
Hit:12 https://pkg.tox.chat/debian nightly
InRelease
Ign:13 http://ftp.debian.org/debian wheezy InRelease
Hit:14 http://ftp.debian.org/debian wheezy
Release
Ign:16
http://download.opensuse.org/repositories/home:/stevenpusser/Debian_8.0
InRelease
Hit:17
http://download.opensuse.org/repositories/home:/stevenpusser/Debian_8.0
Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
~# apt-file search evemu*
~# apt-file search evemu-record
~# apt-file search `which evemu-record`
~# apt-cache search evemu-tools
evemu-tools - Linux Input Event Device Emulation Library - test tools

Is there anything I am missing at my end or is it a known issue?

-- 
Regards,
Yevgeny
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why am I being stonewalled (GRSecurity discussion)?

[Se7en]

On Tue, Jul 25, 2017 at 03:18:25AM +, aconcernedfoss...@airmail.cc wrote:
> Why am I being stonewalled from the discussion now?

So you were kicked out of a discussion thread for being weird, you go
to 8chan to complain, they figure out you're a sockpuppet of
MikeeeUSA, and then you leave there and come to the devuan mailing
list and don't even put OT in the subject header.

Mikeee, you're a weirdo and outside of maybe 10 people no one thinks
you are even competent.

-- 
|-/   | Se7en
 /  The One and Only! | se7en@cock.email
/ | 0x73518A15BA3C1476
   /  | http://koolkidsklub.tech/~se7en
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Why am I being stonewalled (GRSecurity discussion)?

[aconcernedfossdev]

Why am I being stonewalled from the discussion now?

I started the discussion, now because you all believe Bruce Peren's 
libel that I "don't know what I'm talking about" (after he wrote an 
article based on my council...) and his public sanction against me 
because HE didn't understand the importance of brainstorming any and all 
likely arguments from the other side (because HE is brought in as an 
expert witness only once an action is well underway and doesn't witness 
the work that is done in bringing a case forward from a cold start), I 
am no longer included in the conversation.


I feel I've been wronged and I am very angry about it.

The statement about Grsecurity still stands. Aconcernedfossdev was 
wasting my time with naive argument and I don't have to suffer fools 
gladly.


Thanks

Bruce


https://lists.debian.org/debian-user/2017/07/msg00830.html

OK, I apologize to all who were involved in this conversation. I will 
block further emails from "aconcernedfossdev" and no longer encourage 
him.


Bruce

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd'oh! DNS lib underscore bug bites everyone's favorite init tool, blanks Netflix

[Rick Moen]

Quoting Dragan FOSS (dragan.f...@gmx.com):

> Actually (and TBH..), this is a bug in libidn2, which isn't in
> systemd source tree...at least for now ;>

So, one thing to bear in mind about ElReg is that it's very much a
clickbait site, whose stock-in-trade is pumping up controversy and
scandal out of (usually) rather little.  So, they often play fast and
loose with the truth, and people really should please _not_ expect them
to be a reputable IT news outlet, because they just aren't.  

It appears they're also thin-skinned about that:  An ElReg editor
rejected my comment, with a complaint back to me in e-mail by ElReg
editor Chris Williams claiming the story _did_ make clear the bug isn't
within systemd.  (Dng thread readers and those who read the ElReg story
got the impression they were saying it was a systemd bug, right?  I
did.)

  Subject:  Actually, this isn't a systemd bug, for a change.

  Author Chirgwin did not bother to check basic facts. It turns out the
  error is in the GNU IDN (internationalised domain name) library
  'libidn2', which systemd's sometimes-installed-but-optional
  systems-resolved component will use if the library exists. Note that the
  recommended workaround was to recompile systems-resolved to ignore
  libidn2.

Now, it's their feedback forum, and if they really insist on selectively
suppressing critics, that's their privilege, but IMO it doesn't reflect
credit on them.

To be fair, as Mr. Williams says to me in his private mail, the article does 
mention (five paragraphs down) that the problem got isolated down to
libidn2, but nowhere says libidn2 isn't a systemd lib, and meanwhile the
story's headline and opening paragraphs suggested systemd as root cause.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Hendrik Boom]

On Mon, Jul 24, 2017 at 08:57:21PM +0100, Arnt Gulbrandsen wrote:
> Hendrik Boom writes:
> >How much source code actually cares whether pointers are 32 or 64 bits?
> >How many packages are ctually affected?
> >Any guesses?
> 
> a+b.
> 
> a = the number of things whose maintainers all use 64-bit OSes, and chance
> to have a relevant bug. Given the number of small teams, I'm not at all
> surprised if a hundred or more of the tens of thousands of debian packages
> are affected.

Is Debian planning to cut 32-bit support?  If not, we'd have to be 
concerned ony with the subset of those packages with systemd 
dependencies.

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd'oh! DNS lib underscore bug bites everyone's favorite init tool, blanks Netflix

[Alessandro Selli]

On Tue, 25 Jul 2017 at 00:13:08 +0200
Dragan FOSS  wrote:

> On 07/24/2017 11:37 PM, Ozi Traveller wrote:
> > https://www.theregister.co.uk/2017/07/24/underscore_domain_name_bug/
> >
> > Oops!  
> Actually (and TBH..), this is a bug in libidn2, which isn't in systemd 
> source tree...at least for now ;>

  They'll soon develop theyr own version, which will be "much better than the
old one!"  And it will be the foundation of the idn_unicode.socket systemd
unit.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd'oh! DNS lib underscore bug bites everyone's favorite init tool, blanks Netflix

[Alessandro Selli]

On Tue, 25 Jul 2017 at 07:37:10 +1000
Ozi Traveller  wrote:

> https://www.theregister.co.uk/2017/07/24/underscore_domain_name_bug/

  Quote:

«His speculation that libidn2, which adds internationalised domain
names support to the resolver, was at fault turned out to be
accurate. Rebuilding Systemd without that library cleared the
problem.»

  So, this time the source of the problem was not systemd, but a library it
used.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Alessandro Selli]

On Mon, 24 Jul 2017 at 21:52:23 +0200
Ruediger Meier  wrote:

> On Monday 24 July 2017, Joachim Fahrner wrote:
>> Am 2017-07-24 20:34, schrieb Hendrik Boom:  
>>> How much source code actually cares whether pointers are 32 or 64
>>> bits?  
>>
>> Clean written code should not care about pointers or integers are 32
>> or 64 bit or byte order. Code written in a higher language should run
>> on any hardware, otherwise I call it "defect".  
>
> In theory you may have right but in practice I guess most currently used 
> code would not run correctly on 16bit machines.
>
> In practice you have to run and test the code on all target 
> architectures to keep it portable.

  Right.  Remember the Ariane!

https://around.com/ariane.html
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd'oh! DNS lib underscore bug bites everyone's favorite init tool, blanks Netflix

[Rick Moen]

Quoting Dragan FOSS (dragan.f...@gmx.com):

> >Oops!
> Actually (and TBH..), this is a bug in libidn2, which isn't in
> systemd source tree...at least for now ;>

It turns out to be a GNU library:  'Libidn's purpose is to encode and
decode internationalized domain names.'  That's IDN = internationali[sz]ed
domain name.

https://www.gnu.org/software/libidn/

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd'oh! DNS lib underscore bug bites everyone's favorite init tool, blanks Netflix

[Dragan FOSS]

On 07/24/2017 11:37 PM, Ozi Traveller wrote:

https://www.theregister.co.uk/2017/07/24/underscore_domain_name_bug/

Oops!
Actually (and TBH..), this is a bug in libidn2, which isn't in systemd 
source tree...at least for now ;>


*
[dragan@trios-eudev][/media/dragan/TRIOS/LIBSYSD/ORIG-SOURCE/UP-GIT/systemd]$ 
grep -R libidn2

meson.build:want_libidn2 = get_option('libidn2')
meson.build:if want_libidn == 'true' and want_libidn2 == 'true'
meson.build:error('libidn and libidn2 cannot be requested 
simultaneously')

meson.build:if want_libidn != 'false' and want_libidn2 != 'true'
meson.build:if not conf.get('HAVE_LIBIDN', false) and want_libidn2 != 
'false'

meson.build:# libidn is used for both libidn and libidn2 objects
meson.build:libidn = dependency('libidn2',
meson.build:required : want_libidn2 == 'true')
meson.build:['libidn2'],
NEWS:* systemd-resolved may now optionally use libidn2 instead 
of the libidn
NEWS:  for processing internationalized domain names. Support 
for libidn2

README:libidn2 or libidn (optional)
mkosi.default:libidn2-devel
mkosi.default:libidn2
.mkosi/mkosi.fedora:libidn2-devel
.mkosi/mkosi.fedora:libidn2
.mkosi/mkosi.debian:libidn2-0-dev
.mkosi/mkosi.debian:libidn2-0
[dragan@trios-eudev][/media/dragan/TRIOS/LIBSYSD/ORIG-SOURCE/UP-GIT/systemd]$ 


**
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] systemd'oh! DNS lib underscore bug bites everyone's favorite init tool, blanks Netflix

[Ozi Traveller]

https://www.theregister.co.uk/2017/07/24/underscore_domain_name_bug/

Oops!

:)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Arnt Gulbrandsen]

Hendrik Boom writes:

How much source code actually cares whether pointers are 32 or 64 bits?
How many packages are ctually affected?
Any guesses?


a+b.

a = the number of things whose maintainers all use 64-bit OSes, and chance 
to have a relevant bug. Given the number of small teams, I'm not at all 
surprised if a hundred or more of the tens of thousands of debian packages 
are affected.


b = the number of packages whose memory usage is heavily pointer-dependent 
and that are used in big deployments. That does exist (say among people who 
bin-pack microserver shards across iron to fill both RAM and CPU capacity) 
but I'm willing to be that for devuan's purpose b<π (those people compile).


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] running old stuff

[Simon Hobson]

Hendrik Boom  wrote:

> On Sun, Jul 23, 2017 at 09:17:29PM +0100, Simon Hobson wrote:
>> 
>> So the analogy is, I wouldn't expect "support" for all this "new" 
>> stuff on an old vehicle. Similarly, as other have suggested, if I 
>> was running very old hardware, I'd probably not be too worried about 
>> being able to run all the latest and greatest software on it.
> 
> And why think that the latest software is the greatest.

I don't - it's a turn of phrase "latest and greatest". I forget about the 
number of people here with different cultural backgrounds.

> Bugfixes make 
> old software better, and so in that sense later is greater, but for 
> the most part I see a lot of new software be buggy and bloated.
> I wouldn't want a lot of this new-fangled stuff on any machine, new or 
> old.

I agree. I frequently look at the newer versions and think something along the 
lines of "what a pile of ", especially with things like MS changing the UI 
whenever there's an R in the month !

>> So there's an argument for dropping support for an old and little used 
>> architecture for NEW VERSIONS - leave the older versions in the 
>> repos so that people can still install a system, but make it clear 
>> that this won't be the latest and greatest version. There then comes 
>> the issue of ongoing bugfixes - and my assumption would be that only 
>> serious and/or security related bugs would get fixed in it.
> 
> In a world where most of the new hardware contains unauditable 
> firmware, that's tantamount to giving up any hope for security.

It's all a balancing act. How much effort to put into updates for "old" stuff - 
do you keep supporting version1, 2, 3, ... when the package is up to whatever 
number it is ? And what level of support - security fixes, other bug fixes, 
feature upgrades ?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Joachim Fahrner]

Am 2017-07-24 20:34, schrieb Hendrik Boom:


How much source code actually cares whether pointers are 32 or 64 bits?


Clean written code should not care about pointers or integers are 32 or 
64 bit or byte order. Code written in a higher language should run on 
any hardware, otherwise I call it "defect".


And concerning the memory usage: don't forget, mixing 32/64 bit shared 
libraries doubles the memory needs. Sharing of libraries only makes 
sense if they are really shared, otherwise you can link programs static. 
BTW: That's an illness on windows, where every application brings it's 
own "shared" library version x.y, that never becomes really shared.


Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Hendrik Boom]

On Mon, Jul 24, 2017 at 09:31:46AM +0200, Jaromil wrote:
> On Sun, 23 Jul 2017, Hendrik Boom wrote:
> 
> > Please help keep 32-bit architecture alive.  I've been running
> > Devuan since the alpha-2 release.
> 
> Knowing well the aims and values of our team I can already say noone
> is intentioned in dropping 32bit. The only constraints affecting our
> priorities are due to availability of people working with us towards
> such common goals.
> 
> To keep the 32bit alive is a new challenge the Devuan team is willing
> to take up and I believe that, once we are done powering up our
> infrastructure, we'll be able to facilitate even more participation.
> 
> At this stage people and can help us joining the development team to
> help with package maintainance, organisations and companies can help
> us donating an hosted server, everyone can help us with donations and
> perhaps even bigger sponsorships. The 32bit preservation challenge is
> a new one justifying such a request for even more support.

How much source code actually cares whether pointers are 32 or 64 bits?
How many packages are ctually affected?
Any guesses?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] running old stuff

[Hendrik Boom]

On Sun, Jul 23, 2017 at 09:17:29PM +0100, Simon Hobson wrote:
> 
> So the analogy is, I wouldn't expect "support" for all this "new" 
> stuff on an old vehicle. Similarly, as other have suggested, if I 
> was running very old hardware, I'd probably not be too worried about 
> being able to run all the latest and greatest software on it.

And why think that the latest software is the greatest.  Bugfixes make 
old software better, and so in that sense later is greater, but for 
the most part I see a lot of new software be buggy and bloated.
I wouldn't want a lot of this new-fangled stuff on any machine, new or 
old.

> So there's an argument for dropping support for an old and little used 
> architecture for NEW VERSIONS - leave the older versions in the 
> repos so that people can still install a system, but make it clear 
> that this won't be the latest and greatest version. There then comes 
> the issue of ongoing bugfixes - and my assumption would be that only 
> serious and/or security related bugs would get fixed in it.

In a world where most of the new hardware contains unauditable 
firmware, that's tantamount to giving up any hope for security.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [Desktop-Environment] Cinnamon and MATE

[Harald Arnesen]

Adam Borowski [2017-07-23 12:57]:

>> > I run 32-bit Devuan on one Core2 machine. Why? I can't get Xerox'
>> > proprietary printer driver for their Phaser 6010N color laser to work on
>> > 64-bit. Several receipes on how to do this, none of them work.

> Printer drivers work in userspace, not in kernel.  64-bit x86 kernels can
> run i386 binaries just fine -- usually better than a 32-bit kernel would,
> as there's no mucking with inadequate address space.

Yes, I can probably run a 64-bit kernel on this machine, and still have
an exclusively 32-bit userspace.

> And on De??an, there's multiarch so you can mix-and-match binaries.
> I don't know much about printing (I don't own a printer nor have a reason
> to use one more than once per ~2 years), but AFAIK printer drivers are
> separate processes so there's no ABI problem whatsoever.

In theory, yes. I have tried just that, and it didn't work. I will try
again tomorrow, when I see this printer again.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Devuan Security Advisory

[Juergen Moebius]

Hi folks,

is there an Security Advisory Announcement for Devuan?
I mean something like this:
"debian-security-annou...@lists.debian.org"

Or should I continue receive this from Debian?

Thanks,
Juergen Moebius
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Upgrade from Debian Wheezy

[Brad Campbell]

G'day All,

I have a couple of production machines running Debian 7.11. One of those 
has a twin I use for staging and I routinely rsync the prod box across 
to ensure I'm testing in as accurate a replica as I can get.


Upgrade time is coming, and I'm migrating to Devuan Jessie.

This environment is a bit of a bitza with home-made backports of things 
like e2fsprogs, mdadm and plenty of supporting libraries plus custom 
grub configs, kernels and the usual gumph that is the result of a dist 
upgrade from Squeeze, and as-required piecemeal patchwork to keep things 
stable over the last 6 years or so.


I'm happy to say the staging box went through a relatively seamless 
upgrade with no apparent fallout. Nice. Better still, I can lose all the 
custom compiled stuff and go back to a standard install.


I'll be re-doing the upgrade a few times to ensure I catch all the 
little config file niggles that will need tweaking, but I was fairly 
blown away with how easy it was, given my experience "upgrading" to 
Debian Jessie during the late testing phase often resulted in wreckage 
and an unbootable box.


I've been used to Debian upgrades being seamless over the last 20 years 
or so, and they have been until the wreck that was Jessie, so it's nice 
to go back to a stable base that won't move stuff around under me, 
re-name all my network adapters and just fail to boot far enough into a 
system to allow me to recover when I do something dumb.


Two thumbs up to the faceless volunteers that make all this machinery 
happen.


Regards,
Brad
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Arnt Karlsen]

On Sun, 23 Jul 2017 21:22:03 -0700, Rick wrote in message 
<20170724042203.gq7...@linuxmafia.com>:

> Quoting Enrico Weigelt, metux IT consult (enrico.weig...@gr13.net):
> 
> > Some more: I'm still running 32bit userland even on 64bit machines,
> > to save some memory. Especially for applications that heavily use
> > pointers, it does make a notable difference.
> 
> Yes, the fact that x86_64 (and other 64-bit) pointers each chew up 8
> bytes[1] (64 bits) wide, and thereby gobble 2x the RAM, each,
> compared to IA32, can be a significant problem in code that uses
> pointers a great deal, and is very vexing.  This irritation's
> inescapable in 64-bit-compiled code, because those pointers need to
> be able to hold the address of any valid memory location the CPU can
> address, whereas 32-bit pointers can reach 4GB address space (which
> seemed impossibly large not so long ago).[2]
> 
> So, yes, IA32 compilation (preferably in an otherwise x86_64 host, as
> you're doing) is just the thing for being RAM-thrifty if you don't
> need to access TB of RAM and the code is making heavy use of pointers.
> 
> Wikipedia's article on 64-bit computing says:
> 
>   The main disadvantage of 64-bit architectures is that, relative to
>   32-bit architectures, the same data occupies more space in memory
> (due to longer pointers and possibly other types, and alignment
> padding). This increases the memory requirements of a given process
> and can have implications for efficient processor cache use.
> Maintaining a partial 32-bit model is one way to handle this, and is
> in general reasonably effective. 
> 
> So, yay for a partial IA32 model within an x86_64 environment:
> smaller pointer-heavy binaries where you need them, but also software
> access to up to 8TB physical RAM (and 4 exabytes = 2^64 of virtual
> memory) where you don't -- best of both worlds.
> 
> And, don't forget, year 2038 effects beckon, starting long before
> 2038.
> 
> 
> [1] There are three distinct data-type models for 64-bit:  ILP64,
> LLP64, and LP64.  But all have 8-byte pointers.  The differences lie
> in lengths of non-pointer data types.
> 
> [2] What really changed my mind about this is VM technology.  Ability
> to have the production server host in one VM and the beta in another,
> and the small host OS doing security & other monitoring of both, is
> cool. ___


..one possible fix: https://wiki.debian.org/X32Port minus systemd


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please keep 32-bits alive

[Jaromil]

On Sun, 23 Jul 2017, Hendrik Boom wrote:

> Please help keep 32-bit architecture alive.  I've been running
> Devuan since the alpha-2 release.

Knowing well the aims and values of our team I can already say noone
is intentioned in dropping 32bit. The only constraints affecting our
priorities are due to availability of people working with us towards
such common goals.

To keep the 32bit alive is a new challenge the Devuan team is willing
to take up and I believe that, once we are done powering up our
infrastructure, we'll be able to facilitate even more participation.

At this stage people and can help us joining the development team to
help with package maintainance, organisations and companies can help
us donating an hosted server, everyone can help us with donations and
perhaps even bigger sponsorships. The 32bit preservation challenge is
a new one justifying such a request for even more support.


ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng