Re: [DNG] Trouble with apt-get upgrade over TOR

2017-10-24 Thread Fungal-net 
> From: kato...@freaknet.org
> To: dng@lists.dyne.org
>
> On Tue, Oct 24, 2017 at 10:26:01AM -0400, Fungal-net wrote:
>
> [cut]
>
>>
>> I reported the same in the forum and although I did not get an answer yet
>> when earlier today I was trying to figure it out I changed all rep"s 
>> /merged/ to
>> /devuan/ and I got working releases. The /merged/ directories of the 
>> repositories
>> seem to not have been updated for a couple of months.
>> I think this works for all ascii, ceres, experimental.
>> Ohh.. and there was an update in one of the refracta pkgs as well :)
>>
>
> That"s totally wrong. You should not replace /merged with /devuan
> otherwise you won"t get any package at all, except those forked by
> Devuan.
>
>> But it would be nice if one of the insideres would clarify this information 
>> as
>> there has been ambiguity on what is what for 3-4 days now.
>> The confusing issue is that pkgmaster or whatever is called with amprolla3
>> in the announcement says /merged/ while they say all onion is on pkgmaster
>> but only /devuan/ works.
>
> I don"t understand what you refer to, since many users are using the
> onion address and have no problems with that. The onion address works
> as the normal pkgmaster.devuan.org, and changing /merged with /devuan
> is not solving your problem, only eliminating it in the wrong way
> (since you will miss all the packages that were not forked by Devuan,
> which are an overwhelming majority).
>
> The Devuan onion address works by redirecting requests of non-devuan
> packages to a Debian onion repo. If you onion configuration is
> correct, you should be able to use the repos without errors.
>
> If you could be so kind to show what error you get, we might try to
> nail the cause down.

The repository is not updated and the previous index files will be used. GPG 
error: tor://devuanfwojg73k6r.onion/merged ascii InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY BB23C00C61FC752C___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Trouble with apt-get upgrade over TOR

2017-10-24 Thread Fungal-net 
> From: a...@iaksess.no
> To: dng@lists.dyne.org
>
> On Mon, 23 Oct 2017 13:45:48 -0500, lpb+dev...@kandl.houston.tx.us
> wrote in message
> 3b6863f4-a35a-8b41-b09a-333778dab...@kandl.houston.tx.us:
>
>> I'm having trouble doing an "apt-get upgrade" over tor+http. The
>> update works fine; my guess is the manifests have bad information.
>> Here's what a session looks like (see below). Am I doing something
>> wrong?
>> I would have posted this to the bug tracker but I'm not sure to which
>> package to assign it.
>>
>> ..try 'reportbug apt-transport-tor', if you don't have it installed,
>> you'll see:
>> "Getting status for apt-transport-tor...
>> No matching source or binary packages.
>> A package named "apt-transport-tor" does not appear to be installed; do
>> you want to search for a similar-looking filename in an installed
>> package [Y|n|q|?]?"
>>
>> ..if you have it installed, just follow reportbug's promts.
>>
>> ..search tip: 'apt-cache search apt-transport ' yields:
>> apt-transport-https - https download transport for APT
>> apt-transport-spacewalk - APT transport for communicating with
>> Spacewalk servers
>> apt-transport-tor - APT transport for anonymous package downloads via
>> Tor
>>
>> --
>> ..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.

I reported the same in the forum and although I did not get an answer yet
when earlier today I was trying to figure it out I changed all rep's /merged/ to
/devuan/  and I got working releases.  The /merged/ directories of the 
repositories
seem to not have been updated for a couple of months.
I think this works for all ascii, ceres, experimental.
Ohh..  and there was an update in one of the refracta pkgs as well :)

But it would be nice if one of the insideres would clarify this information as
there has been ambiguity on what is what for 3-4 days now.
The confusing issue is that pkgmaster or whatever is called with amprolla3
in the announcement says /merged/  while they say all onion is on pkgmaster
but only /devuan/ works.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Trouble with apt-get upgrade over TOR

2017-10-24 Thread Fungal-net 
> From: kato...@freaknet.org
>
>> To: dng@lists.dyne.org
>>
>> On Tue, Oct 24, 2017 at 10:26:01AM -0400, Fungal-net wrote:
>>
>> [cut]
>>
>>>
>>> I reported the same in the forum and although I did not get an answer yet
>>> when earlier today I was trying to figure it out I changed all rep"s 
>>> /merged/ to
>>> /devuan/ and I got working releases. The /merged/ directories of the 
>>> repositories
>>> seem to not have been updated for a couple of months.
>>> I think this works for all ascii, ceres, experimental.
>>> Ohh.. and there was an update in one of the refracta pkgs as well :)
>>>
>>
>> That"s totally wrong. You should not replace /merged with /devuan
>> otherwise you won"t get any package at all, except those forked by
>> Devuan.
>>
>>> But it would be nice if one of the insideres would clarify this information 
>>> as
>>> there has been ambiguity on what is what for 3-4 days now.
>>> The confusing issue is that pkgmaster or whatever is called with amprolla3
>>> in the announcement says /merged/ while they say all onion is on pkgmaster
>>> but only /devuan/ works.
>>
>> I don"t understand what you refer to, since many users are using the
>> onion address and have no problems with that. The onion address works
>> as the normal pkgmaster.devuan.org, and changing /merged with /devuan
>> is not solving your problem, only eliminating it in the wrong way
>> (since you will miss all the packages that were not forked by Devuan,
>> which are an overwhelming majority).
>>
>> The Devuan onion address works by redirecting requests of non-devuan
>> packages to a Debian onion repo. If you onion configuration is
>> correct, you should be able to use the repos without errors.
>>
>> If you could be so kind to show what error you get, we might try to
>> nail the cause down.
>
> The repository is not updated and the previous index files will be used. GPG 
> error: tor://devuanfwojg73k6r.onion/merged ascii InRelease: The following 
> signatures couldn't be verified because the public key is not available: 
> NO_PUBKEY BB23C00C61FC752C

I think I'm getting somewhere.
The merged repositories will not update because the key is expired.  One would 
have to revert to the /devuan/ update the keyring and re-edit the repositories 
with the new key to be able to upgrade.
But what about proposed-updates, is this devuan or merged?
I think there is proposed-security as well.

The installation I normally use and was checked frequently didn't have the same 
problem as the ones that have been unattended for a month or two.  Somehow it 
seems as the keyring was updated before the pkgmaster deal and that makes the 
difference.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..proper use of /merged and /devuan, was: Trouble with apt-get upgrade over TOR

2017-10-24 Thread Fungal-net 
>>> On Tue, 24 Oct 2017 18:26:45 +0100, KatolaZ wrote in message


> jessie-proposed is under /devuan
> jessie-proposed-updates is under /devuan
> experimental is under /devuan

> The rest is under /merges, if I have not missed something.

I did not ask because I wanted to blame anyone, but asked so I can solve a 
problem
The above instructions are what they SHOULD be and this is HOW THEY WERE.
Since the keyring was not updated prior to the shift to amprolla3 all the 
merged repositories were invalid, and this is where the new keyring was.
Only by switching the merged into devuan was I able to update the key, I just 
didn't realize I had to rechange back to merged.  But merged were inaccessible 
without the key.

Why not go and delete your /etc/apt/trusted.gpg.d and see if you can install 
the keyring from /merged
I couldn't!   I could from /devuan!
If that is true then the instructions to switch from Debian/jessie to 
Devuan/jessie with onion addresses are invalid.  So try not to shove this under 
the carpet, yet.
In any case my question was about -ascii and -ceres not about -jessie but I 
will have to make the deduction, which has proven many times in the past to be 
false.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..proper use of /merged and /devuan, was: Trouble with apt-get upgrade over TOR

2017-10-26 Thread Fungal-net 
Ok, this is the message by fsmithred I was referring to on my previous note.

> From: fsmith...@gmail.com
> To: dng@lists.dyne.org
>
> My understanding is that for anything found under /merged on the server,
> you should use /merged in your sources, and anything found ONLY under
> /devuan needs to have /devuan in the sources. Below are the directory
> listings from pkgmaster.devuan.org showing jessie, ascii and ceres, for
> both /merged and /devuan. I marked the ones that are unique to /devuan
> with a star.
>
> https://pkgmaster.devuan.org/merged/dists/
> ascii/ 11-Aug-2017 09:46
> ascii-backports/ 11-Aug-2017 09:46
> ascii-proposed-updates/ 04-Sep-2017 09:51
> ascii-security/ 11-Aug-2017 09:45
> ascii-updates/ 11-Aug-2017 09:45
> ceres/ 11-Aug-2017 09:45
> jessie/ 11-Aug-2017 09:44
> jessie-backports/ 22-Oct-2017 10:58
> jessie-proposed-updates/ 11-Aug-2017 09:42
> jessie-security/ 11-Aug-2017 09:42
> jessie-updates/ 11-Aug-2017 09:42
>
> https://pkgmaster.devuan.org/devuan/dists/
> ascii/ 25-Oct-2017 10:02
> ascii-backports/ 25-Oct-2017 10:02
> *ascii-proposed/ 25-Oct-2017 10:02
> *ascii-proposed-security/ 25-Oct-2017 10:02
> ascii-proposed-updates/ 25-Oct-2017 10:02
> ascii-security/ 25-Oct-2017 10:02
> ascii-updates/ 25-Oct-2017 10:02
> ceres/ 25-Oct-2017 10:02
> *experimental/ 25-Oct-2017 10:02
> jessie/ 25-Oct-2017 10:02
> jessie-backports/ 25-Oct-2017 10:02
> *jessie-proposed/ 25-Oct-2017 10:02
> *jessie-proposed-backports/ 25-Oct-2017 10:02
> *jessie-proposed-security/ 25-Oct-2017 10:02
> jessie-proposed-updates/ 25-Oct-2017 10:02
> jessie-security/ 25-Oct-2017 10:02
> jessie-updates/ 25-Oct-2017 10:02___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] many many 404 when upgrading/installing packages

2017-10-26 Thread Fungal-net 
From: fulanope...@cryptolab.net

> To: dng@lists.dyne.org
>
> KatolaZ:
>> On Mon, Oct 23, 2017 at 01:15:08PM +, Fulano Diego Perez wrote:
>>>
>>>
>>> KatolaZ:
 # apt-get update

 before trying to install/upgrade packages? One reason why you might
 have a 404 is that the cache kept by apt is older than the actual
 version.
>>>
>>> dont be sorry.
>>>
>>> yes, did the obvious updates ..
>>
>> OK. Could you please retry and report which packages give a 404, and
>> also post the relevant sections of your sources.list?
>
> i just went back to default for now...

It could that going back may not be giving you a 404 error but you may have the 
incorrect
repository.
Based on advise passed yesterday by fsmithred on Dev1.galaxy forum I compiled a 
complete list of repositories as found on pkgmanager.
According to fsmithred those that are both on devuan and merged should be on 
merged.  Those that are only on devuan and not merged should only be on devuan.

So the complete list to pick from (some are optional repositories) is this:

deb https://pkgmaster.devuan.org/merged/ ascii main contrib non-free
deb https://pkgmaster.devuan.org/merged/ ascii-backports main contrib non-free
deb https://pkgmaster.devuan.org/merged/ ascii-proposed-updates main contrib 
non-free
deb https://pkgmaster.devuan.org/merged/ ascii-security main contrib non-free
deb https://pkgmaster.devuan.org/merged/ ascii-updates main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ ascii-proposed main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ ascii-proposed-security main contrib 
non-free
deb https://pkgmaster.devuan.org/merged/ ceres main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ experimental main contrib non-free
deb https://pkgmaster.devuan.org/merged/ jessie main contrib non-free
deb https://pkgmaster.devuan.org/merged/ jessie-backports main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ jessie-proposed main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ jessie-proposed-backports main contrib 
non-free
deb https://pkgmaster.devuan.org/devuan/ jessie-proposed-security main contrib 
non-free
deb https://pkgmaster.devuan.org/merged/ jessie-proposed-updates main contrib 
non-free
deb https://pkgmaster.devuan.org/merged/ jessie-security main contrib non-free
deb https://pkgmaster.devuan.org/merged/ jessie-updates main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ sid main contrib non-free
deb https://pkgmaster.devuan.org/merged/ stable main contrib non-free
deb https://pkgmaster.devuan.org/merged/ stable-backports main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ stable-proposed main contrib non-free
deb https://pkgmaster.devuan.org/merged/ stable-proposed-updates main contrib 
non-free
deb https://pkgmaster.devuan.org/merged/ stable-security main contrib non-free
deb https://pkgmaster.devuan.org/merged/ stable-updates main contrib non-free
deb https://pkgmaster.devuan.org/merged/ testing main contrib non-free
deb https://pkgmaster.devuan.org/merged/ testing-backports main contrib non-free
deb https://pkgmaster.devuan.org/devuan/ testing-proposed main contrib non-free
deb https://pkgmaster.devuan.org/merged/ testing-proposed-updates main contrib 
non-free
deb https://pkgmaster.devuan.org/merged/ testing-security main contrib non-free
deb https://pkgmaster.devuan.org/merged/ testing-updates main contrib non-free
deb https://pkgmaster.devuan.org/merged/ unstable main contrib non-free

deb tor://devuanfwojg73k6r.onion/ should be replaced to use the onion address 
or you could add tor+https://pkg  to use tor without onion addresses.

After I corrected the merged/devuan confusion on a proposed.. repository the 
404 error went away.  The incorrect repository before the amprolla3 switch was 
not producing an error. This is on a really old 32bit machine running jessie, 
it is unrelated to the issue I talked about a couple of days ago.

I hope this helps to end the confusion.  I think some of those repositories, 
like sid, may be empty but that is not a 404 error, or the side that has 
non-free may be empty.  I hope that someone will verify this list is correct 
before my mistake or misperception spills more panic.

PS  For https and tor you need apt-transport-https & apt-transport-tor 
otherwise substitute http from the list, right?

PS2  The tor-project repositories are:
deb tor://sdscoq7snqtznauu.onion/torproject.org/ stretch main
deb tor://sdscoq7snqtznauu.onion/torproject.org/ 
tor-experimental-0.3.2.x-stretch main
or https://deb.torproject.org/torproject.org
but you must first import the gpg key___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Amprolla3 is out for testing

2017-10-22 Thread Fungal-net 
I am still unclear on what the onion repositories are and what our choice is at 
this stage.  Are we on amprolla3?  Are debian's non onion addressed used 
automatically during upgrade or is it an illusion to see http://debian  
through while the update takes place?___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-22 Thread Fungal-net 
> From: sl...@troubleshooters.com
> To: dng 
>
> Hi all,
>
> I basically said UEFI is junk and Secure Boot is an anti-small-distro
> monopolistic practice. These were, and continue to be, my opinions, but
> they're just one man's opinion. I can see use cases where Secure Boot
> would be great, and I can see cases where something like UEFI would be
> handy: But they're neither necessary nor wanted on MY computers.

I've been following this debate and I can't seem to have interpreted your
argument any other way.  Where I am losing the value of it is whether our
opinions, developed by exposure to debate, have any implications on how the
hw industry behaves.  And then who this industry is?  We are talking about two
architects predominantly, mandating their architecture to a handful of boards
and chip makers, and a small handful of reseller-designers (Dell, HP, Lenovo, 
Toshiba)
who package this up.  To us a distro with 400 users is a big deal, to them a 
sale
of 400 boxes is negligible.  Bios was pretty monolithic in itself, I believe, 
but ever
since the original PC-xt we didn't have much of an option.  Nobody complained
about the middle-chip-man back then.

What I would underline in the argument is whether this shift affects little 
distros
more than the big systems who can afford to adopt to the change.  How many
installers are capable to adopt via the common iso-->usb booting in bios or efi?
How easy is it for inexperienced user to know whether they should download
an efi iso or bios?  Everytime in all retail industry a mono/oligopoly is 
attempted to
be built, to narrow the spectrum of choice, it is covered up with a 
safety/security
of the consumer propaganda.  And there are trolls that get paid to spread this
propaganda around in media.  You name me one industry that this is not common
practice for the "big guys" to take out the "little guys" by selling security 
and
safety to the terror victims.  Food, transportation, building, energy, ...
Then there are factory installed linux systems, ubuntu, manjaro, ... is there 
one
that installs a non-systemd system?

Steve Litt is technically correct in pointing the technical aspects of this out 
but
his arguments are normally sterilized from what this really means.  They are
politically in a vacuum of content.  Whether I and Tobias agree or disagree is
irrelevant to Toshiba.

> If I had a real choice to stick with MBR and always be able to disable
> Secure Boot, the world would be fine. We'd all make our choice, and
> we'd all be happy.

Well I liked 2stroke motors too, but they were banned not on their mechanical
merits but with the excuse of not being environmentally correct, just because
it was more profitable and easier for the competition to adopt to such 
restriction.
Mr Honda himself who made fine 2strokes had promised to make them vanish.
A generation later a youngster believes it is common practice and socially
acceptable to pay 150euro/$ for semi-annual "service".  And Europe is covered
up with a carcinogenic diesel cloud, the SE Asia rainforest is vanishing to 
produce
biodiesel for C/W europe, and it is all for the profitability of VW and other 
gangsters.

> But you don't know if you can turn off Secure Boot until you've bought
> the mobo or computer. This ability, which is the #1 priority for me,
> doesn't even make it to the specifications. There's no way to find out.
> THAT's why I hate Secure Boot.

Tell us, as I don't know enough, which system is more secure in booting
a portable LUKS encrypted disk.  Can it be done with EFI easier?  This
was known and available technology before secure boot.

> Similar for UEFI. I don't like its architecture, for exactly the same
> reason I don't like KDE and I don't like systemd: Monolithic
> entanglement. Hey, my preference is to have modules communicate on a
> need to know basis. Others may differ: All I wish is that we all had
> our choice.

So you are stuck using 5-10 year old pcs which in 10 years will be few
and scarce and a minimalist linux system will require 2GB to idle.  So
who cares about your choice.  If you scan google for mimimalist linux
screenshots and see what those awesome, i3, jwm, systems are running
on, you will have a hard time seeing one on a pre-Efi system.  Next year
you have a hard time finding one running with under 8cores.
So who will debate in Debian, or Arch the merits of continuing non-efi
supported installers?  Look what is happening to 32bit systems, the spectrum
is narrowing day by day.  The attrocity is to hear the argument that in the
name of security 32bit can't be kept in development as all interrelated 
technology
is evolving around 64bit.  So it is more secure to have more complex
architecture than a simpler one.

Again, where is the content of your argument?  What good does it do for
me and you to eventually agree that bicycles should have no registration,
insurance and turnsignals?  This world will still be the same without us.

> So I've

Re: [DNG] Should I, or should I not, make a Devuan VimOutliner package?

2018-01-10 Thread Fungal-net 
UTC Time: January 10, 2018 12:21 AM

> From: dva...@internode.on.net
> To: dng@lists.dyne.org
>
> On 09.01.18 10:52, Steve Litt wrote:
>
>> I'm thinking of making the Devuan VimOutliner package use double comma.
>> I'd take the Debian package and replace all appropriate double
>> backslashes with double commas.
>
> Steve,
> If a foreign distro has forked your original, then in our distro it
> seems entirely reasonable for you as originator to restore the original.
> If the foreign fork failed to identify itself as such, then it is not
> your problem or ours when substituting the original reclaims the
> original name. It is up to the fork to find a way to differentiate
> itself. If our community wants to keep both, then I propose that the
> debian package be renamed vimoutliner-debfork or similar.
>
> That would seem to keep the ducks in a row, without the distasteful
> problem of a fork masquerading as the original. It would also avoid
> future list traffic asking "Why is the devuan VimOutliner package
> backslash-borked??"
>
> Erik

I am with Erik on this one.  The fork should be renamed the one of the 
"originator" should retain its "original" name.

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

[DNG] devuanfwojg73k6r.onion and pkgmaster.devuan.org are they and have they ever been the same?

2018-02-14 Thread Fungal-net 
devuanfwojg73k6r.onion  and pkgmaster.devuan.org are they and have they ever 
been the same?

The reason I am asking is in the past couple of months I witnessed ups and 
downs where there were differences and packages existing on one repository 
naming scheme and the other differed, making upgrade procedures to produce 
different results.  In some cases a few weeks ago and while testing the ascii 
distribution the upgrade through the onion address caused total failure of a 
very functional installation.
A first indication that something was seriously wrong was about the time that 
OpenRC and eudev had made it to ascii but at a different naming scheme than 
they existed in experimental.  Eventually through some help from fsmithred for 
older installations with OpenRC the eudev upgrade was possible in ascii.  In 
new installations of ascii where OpenRC and eudev were to be installed the 
primary problem reappeared as it was evident back in December.  The pkgs were 
there but some dependencies were missing.  Weird as it was switching to the 
pkgmaster.devuan.org names of the repositories the missing pkgs WERE there.

After nearly a month has passed NOBODY from the devuan forum cared to transfer 
this puzzling behavior here.  It is evident as per the archives of this list 
that this problem had appeared before, "before it was announced that the onion 
repositories had been forwarding to pkgmaster without the users knowing that 
they had been kicked over to a beta system", and a fault with "pkgmaster" and 
amprolla3 had been taken care of.  Obviously the problem reappeared later.  
After all kinds of havoc and banning of the person reporting the problem took 
place in the "officially official devuan forum" the behavior of the variability 
of the two claimed identical repositories seemed to have magically cured itself 
yet again.

So here is the bottom line technical question as per advise by devuan forum 
admins to be raised here:
We have repository.corporation.name.com = tziberish.onion and the later one 
points exactly at the same server (claimed to be amprolla3 powered pkgmaster).  
 You udpate on that repository and you get a release file and a gpg key that 
verifies the validity of that release file.  You switch between the two names, 
and it "reloads" updates that file as it is a different "new" file, with the 
same gpg key.  Why is this?  Why if it the same server doesn't apt (or apt-get) 
recognize it as the same release file?

What are the implications of a repository being claimed to be the same with two 
addresses and in fact being a different, even if slightly different, or even if 
the contents are the same but it is actually a different server?  How long were 
onion address users exposed to a beta repository system before they were told 
they had been "pushed over to it"?

Gus, from sysdfree.wordpress.org --> not the same person that was banned from 
the forum.

PS   Since GoLinux had a month to transfer this complaint and this issue here 
for technical advise and chose to keep it a secret from the list, I shall hope 
GoLinux will respect the OP and do not express any opinion on the matter, just 
so tones can be kept at a low level, if that can be possible.

PS2  If one cares to look back at the archives about the following: 
(libcommons-pool-java and eclypse package) problems, one would find that the 
problem had been reported to the list before and there was assurance that the 
problem in amprolla3 had been "fixed".  It seems as the problem wasn't 
permanently fixed or even addressed the correct way.  It was just specifically 
showing as a non-continuing problem.

PS3   Maybe irrelevant, but could ascii exacerbate some problems as going from 
jessie to ascii packages may have a lower number version in ascii than in 
jessie, which makes the installation different than if it was a straight ascii 
build?  And those packages must be devuan specific (or specifically held back) 
as such things wouldn't happen from a true debian repository.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuanfwojg73k6r.onion and pkgmaster.devuan.org are they and have they ever been the same?

2018-02-14 Thread Fungal-net 
 Original Message 
 On February 15, 2018 1:28 AM, KatolaZ <kato...@freaknet.org> wrote:

>On Wed, Feb 14, 2018 at 05:24:27PM -0500, Fungal-net wrote:
>>devuanfwojg73k6r.onion  and pkgmaster.devuan.org are they and have they ever 
>>been the same?
>>
>
> They are the same machine and always have been (since late September
> or early October 2017, more or less). The rewrites on pkgmaster are to
> the corresponding Debian mirrors. The rewrites on the onion address
> are on the corresponding Debian onion address. We don't have control
> on them.

Ohh so it has been "that" long that onion repository users have been beta 
testing amprolla3?  And when has the announcement been placed for users to be 
aware?  

> You won't believe it, but you are not the only one using tor here, but
> apparently the only one reporting problems on tor. Have you considered
> the possibility that there might be a problem either in your config or
> in the way you access the repos via tor?

Apparently you didn't read the whole message or reviewed the archive, but I 
believe you, yourself, was involved in this early december list discussion 
about someone testifying to what I am saying.  Packages available through "the 
other repositories" were not available throug the onion address.  It seems as 
you are aware of the problem that I am reporting as it was reported in the 
forum, before this message appeared on the list.  How long has this been?  Why 
didn't you get involved in the forum when the problem was reported?
If there was a problem on "our" side why didn't it ever appear as a problem in 
any of the mutlitude of debian based installations.  I'd like to think that if 
it is a consequence of a bad practice it would appear in Debian as well.  Not 
once, I assure you.

> You should use tor:// or tor+http:// with the onion address, and
> http:// or https:// with pkgmaster. The reason is that the whole thing
> is based on FQDNs http rewrites., and if you mix them up you might
> experience problems.

Are you saying now, and this is a new take on explaining the unexplainable, and 
please readers feel free to intervene here and point out the obvious to me, 
what is the problem of reaching pkgmaster via tor://pkgmaster.devuan.org?  All 
you would know, being the gate keeper on the repository side, is that someone 
through https:// is reaching pkgmaster from the exit node.  Nothing else!  If 
you can see something, other than "graylisting" tor exit nodes, I am sure the 
torpoject people would like to know.  The difference with an onion address is 
that the connection doesn't go out to clearnet to reach the destination, but 
the target is one and the same.  Right?

I don't know what is going on with the internals of the repository and I don't 
know whether the "users" would care to know.  The questions was simple, are 
they or are they not the same.  What is your response?  Beating around the bush?

How do your internals separate a hit on an onion address from one from clearnet 
so amprolla3 and is forwarding those to the debian.onion address?  This brings 
a new twist into the equation.  You are forwarding one connection out of tor 
and back into tor and onto debian.   I am not sure this is a good idea as far 
as anonymity is concerned.  

   As has been reported by torproject, not yet explained, somehow if you 
make "one connection" through tor, out in clearnet and back through tor your 
identity is revealed.  *

Are you saying this is what amprolla3 has been doing since 9-10/2017?

But where has this practice been documented before this "official" 
announcement?  Here you are admitting the onion address is NOT the same with 
packagemaster because the forwarding is done to two separate debian addresses.  
Yoy can only be responsible with your addressing scheme, there is no way for 
you to certify that the debian.org and its onion address are the same, just the 
same way we are trying to establish whether they are in fact the same here.

It is pretty clear on our side that "occassionaly" they have not been as when 
you do an update on pkgmaster and it says no upgrades, and consecutively you do 
the same on the onion address and shows both pkgs to be  upgraded and pkgs to 
be removed (apt-get dist-upgrade), or when in the same time frame openrc and 
eudev were available with dependencies on ascii but dependencies were missing 
through the onion address (no other changes to repository structure, just the 
address).  

> Again: nothing has changed since October in the way we redirect the
> onion address. Nothing at all. Also, even if not relevant,
>pkgmaster.devuan.org and auto.mirror.devuan.org have the very same set
> of packages (pkgmaster gets its package lists from the same source
> auto.mirror gets its package lists), so other speculations about
&

Re: [DNG] Devuan ASCII 2.0.0 Beta released

2018-02-14 Thread Fungal-net 
Please don''t let the Grouch break up your valentine party but would anyone 
care to elaborate on the following scenario?

We have Joe, Jill, Jack, and Mindy.
Joe  is running Wheezy and converts to Ascii
Jill is running Devuan 1 Jessie and converts to ascii
Jack is running Stretch and converts to Ascii
and finally Mindy just installs Ascii-beta-2.0

Don't ask me, I have been running ascii for a quite a while now and my 
experience with Jessie has been from first boot to the second.  And I have run 
OpenRC and eudev ever since they appeared in experimental.

All four of the above have same packages installed in the versions that they 
exist in those 4 situations.

1   Is the end product different?
2   Should the end product be different.
3   The packages that are available and keep upgrading in the debian branch of 
merged, do they appear to all four of them as they do in the debian repository? 
 In other words If you add debian stretch to the repositories the versions "in 
merged ascii" and in stretch should be the same. right?  Live at any given 
minute?  That is what amprolla3 is doing, right?
Are they?

Because as per a couple of hours ago it seems as I have been exposed to this 
amprolla3 for 4-5 months now, without knowing, and although I run about the 
same stuff on a test debian isntallations, pkgs there rain down to the level of 
about 20-30/day, while ascii has been pretty inactive in terms of upgrades.  So 
what exactly is merged with devuan?

 Original Message 
 On February 14, 2018 11:44 PM, Steve Litt  wrote:

>On Wed, 14 Feb 2018 10:48:20 +0100
> Veteran Unix Admins free...@devuan.org wrote:
>
>>Dear dev1rs
>>the Veteran Unix Admins salute you!
>>On February 14th 2015, Devuan unveiled a "pre-alpha" Valentine release
>> of Devuan Jessie [1] just a few months after the Veteran Unix Admins
>> declared their intention to fork Debian on November 27th 2014 [2].
>> That was the beginning of our collective journey. Now, three years
>> later, Valentine's day has more love for the Devuan community.  The
>> long-awaited release of Devuan 2.0 ASCII Beta (minor planet nr. 3568)
>> is here!
>>So what's new in Devuan 2.0 ASCII Beta?
>>
>>
>> - OpenRC is installable using the expert install path
>> (thanks Maemo Leste!)
>>
>> - eudev has replaced systemd-udev (thanks Gentoo!)
>>
>> - elogind has been added as an alternative to consolekit
>> (thanks Gentoo!)
>>
>> - Desktop users can choose among fully functional XFCE (Default), KDE,
>> Cinnamon, LXQT, MATE, and LXDE desktops
>>
>> - CLI-oriented users can select the "Console productivity" task that
>> installs a fully-featured set of console-based utils and tools.
>>
>> - A .vdi disk image is now provided for use with VirtualBox.
>>
>> - ARM board kernels have been updated to 4.14 and 4.15 for most
>> boards.
>>
>>
> Holy cow, you're leaving Debian behind. Our own udev and consolekit
> replacements! Very, very nice!
>
> SteveT
>
>Dng mailing list
>Dng@lists.dyne.org
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

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

Re: [DNG] devuanfwojg73k6r.onion and pkgmaster.devuan.org are they and have they ever been the same?

2018-02-14 Thread Fungal-net 
If you are officially representing Devuan and "a long email" described why 
Devuan should not be trusted, I'd say it is your problem the inability to read 
and understand the technical content.  If you are really unable to understand 
the technical content of this "long email" then you are definetely the wrong 
person to be "officially" responding.

What else is there to say?  If I no longer trust devuan for the very specific 
reasons and evidence I have provided why would I have a technical problem and 
if I did why would I trust you to help me with it?

End of story, I think.  Nowhere in either of my two previous "long messages" 
have I even hinted to a "personal issue or technical problem I need help with".

Your response is every proof I needed that there is something fishy going on.  
It may be legal to be deceiving people but the question is whether it is 
ethical and whether once you discover a rat are you responsible to make the 
discovery public.  That is the dilemma.   There is nothing technical about it!


 Original Message 
 On February 15, 2018 3:04 AM, KatolaZ <kato...@freaknet.org> wrote:

>On Wed, Feb 14, 2018 at 07:43:30PM -0500, Fungal-net wrote:
>
> [cut]
>
>>Obviously the way you are handling the response to me is evidence that there 
>>is something to the story.
>>PLEASE do not forget to point us to the reference on when was there a public 
>>announcement that onion address users were shoved over to a beta testing 
>>system.  I simply have missed it.
>>What I am trying to establish here is trust in devuan's officially announced 
>>means of accessing the repositories.  How important this may be is an other 
>>issue I do not care to discuss here.  We are all mature kids we can think for 
>>ourselves.
>>
>
>
> It is not clear at all what you want to "establish" here.
>
> The officially announced means of accessing Devuan repositories are
> explained at www.devuan.org. The repositories are signed with the
> signatures available in the package devuan-keyring. The fact that the
> onion address points to a server or another is irrelevant. You have to
> trust the signatures on the Release files, and this is done
> automatically by apt. Alternatively, you can download the pubkeys,
> download the InRelease files, and verify them by hand.
>
> You don't seem to have any specific technical issue to point out, only
> rants to vomit. And your preference for writing long emails do not
> help identifying the technical content (if any) which you are
> referring to.
>
> You have not yet provided a technical description of the kind of
> breakage you have experienced, if any.
>
> Please be specific, and we will try to help you.
>
> HTH
>
> KatolaZ
>
>
>[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]
> [ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it ]
> [   @) http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
> [ @@) http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
> [ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
>
>Dng mailing list
>Dng@lists.dyne.org
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

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

Re: [DNG] devuanfwojg73k6r.onion and pkgmaster.devuan.org are they and have they ever been the same?

2018-02-15 Thread Fungal-net 
If we are talking about the technical problem (which did exist) let's talk 
about the technical problem.
If we are talking of the political/security problem let's talk about that.  But 
don't try to make soup out of what we are talking about, and it is to your 
interest to try to understand criticism, despite of the form it is coming from.

Today, and after a lengthy discussion on the onion repository malfunction, 
based on the "new" evidence Katolaz has provided us, there is a speculation of 
the source of the technical problem.  Again and again and in several machines 
and users the problem appeared as "pieces" of the repository been missing.  
Stuff that was in there the day before would be missing but the rest would be 
there from both devuan and debian, and there would be no "error" in updating 
repositories.

AIt seems as obvious now that when amprolla3 tries to merge from 
debian.onion debian has some amprolla like merging system of its 
subrepositories (not all in a single server).  Some of them may be timing out, 
and amprolla3 is not forwarding those errors as partial hits.  

BUsing tor://pkgmaster. ...amprolla3 is hitting the deb.debian.org (or 
some other clearnet address) and it never runs into timing out issues, so 
tor://pkgmaster is always in tact and consistent.  It seems as in the past 2 
weeks someone must have realized what is going on and went in and adjusted the 
timeout threshold, which explains the current consistent results.  Or else, 
there is a limit to how much I can speculate, but something seems to have 
gotten fixed.

CThe political/security issue is that we (users) have been in the blind.  
   1   When someone chose to shift the onion repository address to pkgmaster (a 
beta system) someone should have made an adequate announcement and such was 
never made, not in the webpage not in the "officially official forum" that no 
developer has ever visited.  
   2If the admin of the pkgmaster.devuan.org can distinguish whether a 
connection is using onion or clearnet (apart from tor, they are not the same 
you know, you can use tor to access any clearnet address that has not 
blacklisted all exit nodes, but you can not use http/https to reach an onion 
address) either the server on the onion address is a different server (as 
allowed to conclude by differential parallel results) or it is forwarding those 
connections to "other" servers.  That ability to distinguish the two and act 
based on that distinction is problematic!
   3If a tor connection is made through the tor network and out in the 
clear, and back into tor again (as described by Katolaz) then according to 
torproject the identity of the user can be revealed.  They don't know how it 
happens, they can't yet explain it, but they have warned and reported this for 
a long time.  People abused the abilities of tor and it creates vulnerabilities 
that can't be controlled.  Imagine  a server running tor and feeding an IP to 
another machine and that other machine is running tor a second time.  The 
identity can be revealed, and I don't need to explain to whom or why.


So, thank you, I (we) have been convinced here that "unfortunately" we have 
been right all along, we did our best to report and alert of the problem, 
partially the problem seems to have been silently fixed, but "admins" chose to 
try to shove things under the carpet and maintain a code of silence about it 
till things become explosive.  Because when someone is telling you, hey buddy 
you have a problem.  Hey buddy, this is the problem you have, and the only 
response is "there is no problem, you are crazy", then morally one is obliged 
to make noise and alert victims of the problem denied by authority!

Good bye, and try to be more social when you receive constructive criticism.  
Something that seems to have been long gone in linux environment.

PS  To those asking MORE technical evidence, go to the officially official 
devuan forum and you will find all the specifics.  Ask fsmithred to point it to 
you as he was the only one that took attention and tried some things out to 
figure it out for himself.  Unfortunately by the time he did the problem was 
cured.  When half the dependencies were missing for installing eudev and openrc 
in ascii he couldn't tell why it was happening.

PS2  alessandro ...  I am surprised with this attitude you got so far 
(linux.com) ...  but talking with that tone should be reserved for up close 
conversations you spineless piece of shit hiding behind a terminal.  I'll see 
you at some conference and we can continue.


 Original Message 
 On February 15, 2018 9:49 AM, KatolaZ <kato...@freaknet.org> wrote:

>On Wed, Feb 14, 2018 at 08:21:03PM -0500, Fungal-net wrote:
>>Your response is every proof I needed that there is something fishy going on. 
>> It may be legal to be deceiving people

Re: [DNG] A few days of ASCII Beta -- Some stats

2018-02-19 Thread Fungal-net 
Are you counting all tor exit nodes in those numbers?

 Original Message 
 On February 18, 2018 5:17 PM, KatolaZ  wrote:

>
>Dear Dev1rs,
>
> it has been a few days since Devuan ASCII 2.0.0 Beta was released, and
> we thought it would be nice to look at some stats we have collected on
> our servers (i.e., without considering downloads from mirrors). You
> find the numbers below.
>
> On a related note, Devuan has risen to the 11th position (it was 61st
> on Feb 13th) in the weekly ranking on Distrowatch:
>
>https://distrowatch.com/table.php?distribution=devuan
>
> Their rough count would correspond to a normalised average of about
> 1400 unique visits per day, which could probably put Devuan among the
> top 7/8 on the weekly ranking by next Wednesday. Not bad at all for a
> beta release :)
>
> HND
>
> KatolaZ
>
> -+-+-+-+-
>
> Number of visits to files.devuan.org: 39946 (6656 unique IPs)
> Number of ISO/img downloaded (HTTP): 11725 (2047 unique IPs)
> Number of ISO/img downloaded (RSYNC): ~2000 (70 unique IPs, mostly mirrors)
> Number of access to the announcement: 4758 (3041 unique IPs)
>
> == ISO/img downloads by country (top 10) ==
>
> 2706  United States
> 1484  China
> 840  Germany
> 771  Russian Federation
> 710  Japan
> 500  India
> 426  Italy
> 335  France
> 323  Argentina
> 295  Spain
>
> == Access (non-ISO downloads) by country (top 10) ==
>
> 5646  United States
> 2568  Germany
> 2369  Russian Federation
> 1984  France
> 1281  Netherlands
> 1220  Ukraine
> 1147  Italy
> 1085  Spain
> 944  Czech Republic
> 823  United Kingdom
>
> == ISO/img popularity (# downloads) ==
>
> 4230 desktop-live
> 2812 DVD
> 1169 NETINST
> 661  ARM
> 408  minimal-live
> 376  CD-1
> 217  virtualbox
> 169  qemu
> 57   vagrant
>
> -+-+-+-+-
>
>
>[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]
> [ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it ]
> [   @) http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
> [ @@) http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
> [ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
>
>Dng mailing list
>Dng@lists.dyne.org
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

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