Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235386 > unrolled thread

Re: IRC

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: IRC Greg Wooledge <greg@wooledge.org> - 2021-05-19 19:00 +0200
    Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 19:40 +0200
      Re: IRC Greg Wooledge <greg@wooledge.org> - 2021-05-19 20:10 +0200
        Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 20:20 +0200
          Re: IRC Nicolas George <george@nsup.org> - 2021-05-19 20:30 +0200
            Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 21:10 +0200
          Re: IRC Greg Wooledge <greg@wooledge.org> - 2021-05-19 20:30 +0200
            Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 21:10 +0200
            Re: IRC Reco <recoverym4n@enotuniq.net> - 2021-05-19 21:30 +0200
              Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 21:50 +0200
          Re: IRC Dan Ritter <dsr@randomstring.org> - 2021-05-19 20:40 +0200
            Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 20:50 +0200
              Re: IRC Dan Ritter <dsr@randomstring.org> - 2021-05-19 21:00 +0200
            Re: IRC Gene Heskett <gheskett@shentel.net> - 2021-05-19 22:20 +0200
      Re: IRC Andrei POPESCU <andreimpopescu@gmail.com> - 2021-05-19 21:10 +0200
        Re: IRC Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-05-19 21:20 +0200

#235386 — Re: IRC

On Wed, May 19, 2021 at 12:29:56PM -0400, Polyna-Maude Racicot-Summerside wrote:
> Yesterday I downloaded the virtualbox package from the Ubuntu repository
> (because I just found it's not in Debian anymore) and compiled it on
> Debian. Because all the software that I can't find compiled in the
> Debian normal repository, I get them from either Ubuntu or Kali and
> compile them myself. Yes I compiled all the packages that are in Kali
> but not in Debian, to make my own Buster with Kali software. That was
> "hell of a mess" but as I did it before with Stretch, I already had a base.

I believe most people would refuse to support this system, because it's
not in a state that anyone but you will understand, or know how to
troubleshoot.

If you have an issue with virtualbox specifically, I would suggest you
go to a virtualbox support channel.  They'll know much more about it
than a generic Debian channel does.  The best you'll get out of #debian
is probably a bot factoid that points you to a wiki page and/or bug
reports that describe the issues with virtualbox, and why it was removed
from Debian.

If your real issue is "how do I support my frankendebian built out of
hand-built packages from three different distributions", well, we don't
know, and we don't want to waste our time trying to find out.

[toc] | [next] | [standalone]

#235395

[Multipart message — attachments visible in raw view] — view raw

Hi !

On 2021-05-19 12:57 p.m., Greg Wooledge wrote:
> On Wed, May 19, 2021 at 12:29:56PM -0400, Polyna-Maude Racicot-Summerside wrote:
>> Yesterday I downloaded the virtualbox package from the Ubuntu repository
>> (because I just found it's not in Debian anymore) and compiled it on
>> Debian. Because all the software that I can't find compiled in the
>> Debian normal repository, I get them from either Ubuntu or Kali and
>> compile them myself. Yes I compiled all the packages that are in Kali
>> but not in Debian, to make my own Buster with Kali software. That was
>> "hell of a mess" but as I did it before with Stretch, I already had a base.
> 
> I believe most people would refuse to support this system, because it's
> not in a state that anyone but you will understand, or know how to
> troubleshoot.
> 
> If you have an issue with virtualbox specifically, I would suggest you
> go to a virtualbox support channel.  They'll know much more about it
> than a generic Debian channel does.  The best you'll get out of #debian
> is probably a bot factoid that points you to a wiki page and/or bug
> reports that describe the issues with virtualbox, and why it was removed
> from Debian.
> 
> If your real issue is "how do I support my frankendebian built out of
> hand-built packages from three different distributions", well, we don't
> know, and we don't want to waste our time trying to find out.
> 
Love that kind of non-sense answer...
First, it was only a example as I normally find solution myself.
2nd, if you read what I wrote, it regard to a question specific to
something pretty much Debian. And that is :

Build options set in the buildflags.mk

Now if what you are telling me is :
That all software that I may run on my Linux box that are not inside the
Debian repository will make my system a "frankendebian" and will entitle
myself to be called off-topic and not worth having my message read, then
honestly, I'll simply stop reading mailing list and go on my own.

If this is not a Debian question then tell my what it is ?
"Why did it was chosen to use the -fPIC option in buildflags.mk on the
AMD64 platform and will this matter if I take if off because I'm trying
to build a software that ain't in the repository" (Because software in
the repository got built so will build).

Now no one ask you to waste any time. And if the only time you can take
to help someone is the time that you know can be added to a "bug fixed
database" than that's your choice but be assured that if someone ask for
help, and even if it's a real unique case, that only this person may
have, then I'll be more than happy to help. Because I'm not wasting my
time, but I'm learning and possibly this could be useful if I ever get
something similar in a different situation.

To be open minded doesn't mean you have to crack your head open ;-)

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

[toc] | [prev] | [next] | [standalone]

#235399

On Wed, May 19, 2021 at 01:29:44PM -0400, Polyna-Maude Racicot-Summerside wrote:
> Now if what you are telling me is :
> That all software that I may run on my Linux box that are not inside the
> Debian repository will make my system a "frankendebian" and will entitle
> myself to be called off-topic and not worth having my message read, then
> honestly, I'll simply stop reading mailing list and go on my own.

First of all, this is exactly the kind of attitude I was talking about,
which we see *EXTREMELY FREQUENTLY* from Kali users especially.  If you
behave like this on any of the Debian IRC channels, you will get no help.

Second, no, not all third-party software makes your system unsupportable.
But *packages* that are installed from other distributions most certainly
do.

If you want to install third-party software, do so either by building
upstream NON-PACKAGED sources and installing directly in /opt or
/usr/local, or if you wish to use packages, use them only from trusted
sources.  That *especially* means no PPAs.

(What counts as trusted?  That's an open question, and pretty subjective.
Except for the PPA part.  Everyone agrees on those.)

> If this is not a Debian question then tell my what it is ?

These would be examples of Debian questions which an IRC channel could
reasonably hope to answer:

1) "Why isn't virtualbox in Debian?"

2) "How should I install virtualbox on Debian release _____?"

However, the following is *not*:

3) "I built a custom virtualbox package myself from Kali deb-src, and now
   I'm getting this error...."

That's what we can't support.  Especially in IRC, where questions should
be short and easy, not involving 8-hour diagnostic marathons.

[toc] | [prev] | [next] | [standalone]

#235400

[Multipart message — attachments visible in raw view] — view raw

On 2021-05-19 2:01 p.m., Greg Wooledge wrote:
> On Wed, May 19, 2021 at 01:29:44PM -0400, Polyna-Maude Racicot-Summerside wrote:
>> Now if what you are telling me is :
>> That all software that I may run on my Linux box that are not inside the
>> Debian repository will make my system a "frankendebian" and will entitle
>> myself to be called off-topic and not worth having my message read, then
>> honestly, I'll simply stop reading mailing list and go on my own.
> 
> First of all, this is exactly the kind of attitude I was talking about,
> which we see *EXTREMELY FREQUENTLY* from Kali users especially.  If you
> behave like this on any of the Debian IRC channels, you will get no help.
I am not a Kali user.

> 
> Second, no, not all third-party software makes your system unsupportable.
> But *packages* that are installed from other distributions most certainly
> do.
> 

Why would a package I get from a git repository be supportable but a
package I save some packaging time and get from another source (Kali,
Ubuntu for example) would become unsupportable ?

So you are telling me that support stop as soon I build myself a custom
package but if I build software and put it outside the packaging system,
it's supportable ?

> If you want to install third-party software, do so either by building
> upstream NON-PACKAGED sources and installing directly in /opt or
> /usr/local, or if you wish to use packages, use them only from trusted
> sources.  That *especially* means no PPAs.
> 

And if I build myself a package, for example I packaged all my roms used
for gaming into a deb file, this way it's easy to install and I use a
repository on my local network. By doing it this way, my gf who already
does her updates can also update the pack of roms I got.
So this is bad and make me loose community support ?

I don't install software from PPA.
I save myself some time writing packaging files by getting them from
other source when needed.

If you read what I've wrote.

I built many software using upstream source (git repository) but instead
of writing myself the whole packaging files, I took them from either
Kali or Ubuntu when available.

So if I use a package that is not included in Debian for licensing
reason then I get bad, even if it's something as simple as a one file
utility ?

One reason we use a packaging system that tracks the files installed is
to prevent software from interfering by writing over other packages
files. So you thing about /opt is pretty much non relevant except if I
do build software and don't use the packaging system.

> (What counts as trusted?  That's an open question, and pretty subjective.
> Except for the PPA part.  Everyone agrees on those.)
> 
>> If this is not a Debian question then tell my what it is ?
> 
> These would be examples of Debian questions which an IRC channel could
> reasonably hope to answer:
> 
> 1) "Why isn't virtualbox in Debian?"
> 
> 2) "How should I install virtualbox on Debian release _____?"
> 
> However, the following is *not*:
> 
> 3) "I built a custom virtualbox package myself from Kali deb-src, and now
>    I'm getting this error...."
> 
> That's what we can't support.  Especially in IRC, where questions should
> be short and easy, not involving 8-hour diagnostic marathons.
> 

There's a difference between a plain "I get this error" and the other
way around that is :

I get a error and would like to fix it, I'd like to know why do you guys
enforce -fPIC because maybe you have a good reason and if not, I won't
use this option (and this could solve my problem).

I feel like people just feel good telling others "You are wrong" so they
can feel "right".

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

[toc] | [prev] | [next] | [standalone]

#235401

[Multipart message — attachments visible in raw view] — view raw

Polyna-Maude Racicot-Summerside (12021-05-19):
> Why would a package I get from a git repository be supportable but a
> package I save some packaging time and get from another source (Kali,
> Ubuntu for example) would become unsupportable ?

Because the shortcut that allows you to save some time is (1) a very
privileged part of the system and (2) full of pitfalls.

If you install something in /opt and do it incompetently but not too
much, you cannot break your system. At worst, you break what you were
installing.

If you install a package that was done incompetently but not too much,
through the interactions of dependencies, it can cause all kinds of
problems. In particular it can cause important security updates to be
blocked to preserve the possibly unimportant package.

Oh, and, if you know enough about the packaging system to create your
own packages without causing this kind of problems, then I do not need
to explain that to you, you know this already. So yeah.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#235406

[Multipart message — attachments visible in raw view] — view raw

Hi

On 2021-05-19 2:24 p.m., Nicolas George wrote:
> Polyna-Maude Racicot-Summerside (12021-05-19):
>> Why would a package I get from a git repository be supportable but a
>> package I save some packaging time and get from another source (Kali,
>> Ubuntu for example) would become unsupportable ?
> 
> Because the shortcut that allows you to save some time is (1) a very
> privileged part of the system and (2) full of pitfalls.
> 
> If you install something in /opt and do it incompetently but not too
> much, you cannot break your system. At worst, you break what you were
> installing.
> 
> If you install a package that was done incompetently but not too much,
> through the interactions of dependencies, it can cause all kinds of
> problems. In particular it can cause important security updates to be
> blocked to preserve the possibly unimportant package.
> 

I don't play around with base system packages.

> Oh, and, if you know enough about the packaging system to create your
> own packages without causing this kind of problems, then I do not need
> to explain that to you, you know this already. So yeah.
> 
Thanks for the message but like I already said, the packages I used for
source are mostly because they save me time writing documentation that
already got written.

> Regards,
> 

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

[toc] | [prev] | [next] | [standalone]

#235402

On Wed, May 19, 2021 at 02:15:29PM -0400, Polyna-Maude Racicot-Summerside wrote:
> Why would a package I get from a git repository be supportable but a
> package I save some packaging time and get from another source (Kali,
> Ubuntu for example) would become unsupportable ?

Because things you pull from git and install in /opt or /usr/local or
even $HOME do not interfere with the Debian system.  They don't create
dependency issues within the dpkg database, nor do they overwrite
essential system libraries or files, nor do they cause removal of Debian
packages, etc.

An Ubuntu or Kali package, especially a badly built one, can cause *all*
kinds of havoc.  Even some third-party repositories set up by Debian
developers have been notorious for causing these kinds of problems in
the past -- take a look at the history of the "debian multimedia" package
repositories, in particular.

> So you are telling me that support stop as soon I build myself a custom
> package but if I build software and put it outside the packaging system,
> it's supportable ?

It's not quite that cut-and-dried, but basically: yes.

Packages have a much bigger potential for breaking your system.

> And if I build myself a package, for example I packaged all my roms used
> for gaming into a deb file, this way it's easy to install and I use a
> repository on my local network. By doing it this way, my gf who already
> does her updates can also update the pack of roms I got.
> So this is bad and make me loose community support ?

This is OK if you're competent to do it correctly.  But this is a
specialized task, which the generic #debian channel may not be equipped
to help you with.  We can point you toward beginner tutorials.

For help with any problems you encounter while building your own local
packages, there are some channels on the OFTC network: #packaging and
possibly #debian-mentors, although the latter is really for packages that
are intended to become part of Debian, not personal/local projects.

[toc] | [prev] | [next] | [standalone]

#235407

[Multipart message — attachments visible in raw view] — view raw

On 2021-05-19 2:23 p.m., Greg Wooledge wrote:
> On Wed, May 19, 2021 at 02:15:29PM -0400, Polyna-Maude Racicot-Summerside wrote:
>> Why would a package I get from a git repository be supportable but a
>> package I save some packaging time and get from another source (Kali,
>> Ubuntu for example) would become unsupportable ?
> 
> Because things you pull from git and install in /opt or /usr/local or
> even $HOME do not interfere with the Debian system.  They don't create
> dependency issues within the dpkg database, nor do they overwrite
> essential system libraries or files, nor do they cause removal of Debian
> packages, etc.
> 
> An Ubuntu or Kali package, especially a badly built one, can cause *all*
> kinds of havoc.  Even some third-party repositories set up by Debian
> developers have been notorious for causing these kinds of problems in
> the past -- take a look at the history of the "debian multimedia" package
> repositories, in particular.
> 
I have the deb-multimedia repository in my system but only in source
form so I can easily get sources of package that ain't in Debian for the
version I want. By only having the source I don't risk having problem
arise by doing a install by mistake.

It took me three hours fixing the mess that deb-multimedia did on my GFs
computer. She installed a package and it updated something like 100
library, sometime compiled with non-sense options. Luckily they add the
"dmo" to software version. So I was able to list the bad guys by doing
dpkg -l | grep 'dmo'

I totally understand what you say.
And this is the reason why I build my own package when needed. More than
often will be new version of package that I use ahead of time, for
example a version of Emacs that is still in testing but that I need so I
can get tabnine to work on it.

And even there, so not to get problem with library, I'll do the compile
myself. Because most of the time it will link against the library I
already have installed whereas if I'd go with the binary this would
force me to update some non needed library only because it got linked
against (even if it didn't need it but was built for it because it's the
version that will be used by this specific system).

If I need something with a newer version that it exist in Debian then I
check if it exist in deb-multimedia.
If so, I get it in source form.
I check for the dependencies.
Most of the time, all the dependencies have already been ported into
backports.
So I fix those dependencies to use the naming convention that will make
them rely on backport.
And then I'll compile.
And use...
This is how I got Kodi 18.(something) on Buster.

>> So you are telling me that support stop as soon I build myself a custom
>> package but if I build software and put it outside the packaging system,
>> it's supportable ?
> 
> It's not quite that cut-and-dried, but basically: yes.
> 
> Packages have a much bigger potential for breaking your system.
> 
Like I already said, I already know not to install non trusted package
on my system or dodgy software from unknown developers. For example
BigBlueMachine (a real damn mess).

>> And if I build myself a package, for example I packaged all my roms used
>> for gaming into a deb file, this way it's easy to install and I use a
>> repository on my local network. By doing it this way, my gf who already
>> does her updates can also update the pack of roms I got.
>> So this is bad and make me loose community support ?
> 
> This is OK if you're competent to do it correctly.  But this is a
> specialized task, which the generic #debian channel may not be equipped
> to help you with.  We can point you toward beginner tutorials.
> 
I think you are starting to get the thing here.

I've built many package either from scratch or sometime package that
weren't maintained anymore. But that I wanted to get a newer release. So
I got into the package source in Strech (or even Jessie) so it saved me
time writing some documentation, also sometime I found patches that
we're useful. For example disabling the auto-update as not to cause
problem with dpkg file library for the system.

I've backported software from testing into buster myself, using Docker
container not to trash my whole system. Sometime disabling options that
will cause dependencies problem or will require library not available.

Those are mostly specific package, for example Kodi for my girlfriend.

Or in my case, metasploit-framework with the bunch of Ruby dependencies.
Or simply exploitdb, exploitdb-bin-sploits and exploitdb-papers.


> For help with any problems you encounter while building your own local
> packages, there are some channels on the OFTC network: #packaging and
> possibly #debian-mentors, although the latter is really for packages that
> are intended to become part of Debian, not personal/local projects.
> 

Well I'm already on the mentors and dpkg mailing list.

Maybe my question went in a direction for another mailing list here.

Yes I'm planning to go on an maintain some orphaned package.

I'm now looking at the filezilla and freefem++.
I want to see the changes made from upstream before I go on with this.

Depending on the amount of work involved.

Some package don't require much, you disable the auto-update not to
interfere with dpkg, you set specific options as Debian build options
and voila !
But some other require much more work because they only work on some
architecture, use "custom build system", etc.

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

[toc] | [prev] | [next] | [standalone]

#235411

	Hi.

On Wed, May 19, 2021 at 02:23:40PM -0400, Greg Wooledge wrote:
> On Wed, May 19, 2021 at 02:15:29PM -0400, Polyna-Maude Racicot-Summerside wrote:
> > Why would a package I get from a git repository be supportable but a
> > package I save some packaging time and get from another source (Kali,
> > Ubuntu for example) would become unsupportable ?
> 
> Because things you pull from git and install in /opt or /usr/local or
> even $HOME do not interfere with the Debian system.

It's not true in the case of /usr/local.
Any library that's installed in /usr/local/lib will be processed by
ldconfig (see /etc/ld.so.conf.d/*.conf), possibly leading to all
kinds of mess.

> They don't create dependency issues within the dpkg database, nor do
> they overwrite essential system libraries or files,

But to ld.so any library in /usr/local takes priority over /usr, i.e.
you don't need to overwrite the library to break the binary, providing
ABI-incompatible library at /usr/local (and running ldconfig) is sufficient.
And, last time I've looked at $PATH, /usr/local/bin is listed before
/usr/bin, which can be the source of funny things too.

> An Ubuntu or Kali package, especially a badly built one, can cause *all*
> kinds of havoc.  Even some third-party repositories set up by Debian
> developers have been notorious for causing these kinds of problems in
> the past -- take a look at the history of the "debian multimedia" package
> repositories, in particular.

And this very list contains numerous examples of "I forgot about that
library that I've installed at /usr/local, but it broke X and Y years
after".

Package breakages are bad, there's nothing to argue here. But breaking
ld.so is equally bad.

Reco

[toc] | [prev] | [next] | [standalone]

#235412

[Multipart message — attachments visible in raw view] — view raw

Hi !

On 2021-05-19 3:28 p.m., Reco wrote:
> 	Hi.
> 
> On Wed, May 19, 2021 at 02:23:40PM -0400, Greg Wooledge wrote:
>> On Wed, May 19, 2021 at 02:15:29PM -0400, Polyna-Maude Racicot-Summerside wrote:
>>> Why would a package I get from a git repository be supportable but a
>>> package I save some packaging time and get from another source (Kali,
>>> Ubuntu for example) would become unsupportable ?
>>
>> Because things you pull from git and install in /opt or /usr/local or
>> even $HOME do not interfere with the Debian system.
> 
> It's not true in the case of /usr/local.
> Any library that's installed in /usr/local/lib will be processed by
> ldconfig (see /etc/ld.so.conf.d/*.conf), possibly leading to all
> kinds of mess.
> 

Exactly what I was saying.

>> They don't create dependency issues within the dpkg database, nor do
>> they overwrite essential system libraries or files,
> 
> But to ld.so any library in /usr/local takes priority over /usr, i.e.
> you don't need to overwrite the library to break the binary, providing
> ABI-incompatible library at /usr/local (and running ldconfig) is sufficient.
> And, last time I've looked at $PATH, /usr/local/bin is listed before
> /usr/bin, which can be the source of funny things too.
> 
>> An Ubuntu or Kali package, especially a badly built one, can cause *all*
>> kinds of havoc.  Even some third-party repositories set up by Debian
>> developers have been notorious for causing these kinds of problems in
>> the past -- take a look at the history of the "debian multimedia" package
>> repositories, in particular.
> 
> And this very list contains numerous examples of "I forgot about that
> library that I've installed at /usr/local, but it broke X and Y years
> after".
> 
One reason I prefer Debian over other distribution is all the rules
involved before a package is included into the repository /
distribution. There's common build options imposed that also prevent
some badly coded software to compile, so you get stability, etc.

Also the fact that the package build environment must be self contained
(you can't pull stuff from the web or depend on dependencies outside the
package system) make it even better.

There's software that is for example in Kali or Ubuntu that couldn't be
in Debian because of exactly those reason.
> Package breakages are bad, there's nothing to argue here. But breaking
> ld.so is equally bad.
> 
At least when you build a package, there's some test involved (before
build, for example with the Build-conflict, before install with Break,
etc). And as dpkg keep a list of the files installed, it's somewhat
easier to remove than a package that install itself using a "home brew
script" in /usr/local

> Reco
> 

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

[toc] | [prev] | [next] | [standalone]

#235403

Polyna-Maude Racicot-Summerside wrote: 
> 
> On 2021-05-19 2:01 p.m., Greg Wooledge wrote:
> > On Wed, May 19, 2021 at 01:29:44PM -0400, Polyna-Maude Racicot-Summerside wrote:
> >> Now if what you are telling me is :
> >> That all software that I may run on my Linux box that are not inside the
> >> Debian repository will make my system a "frankendebian" and will entitle
> >> myself to be called off-topic and not worth having my message read, then
> >> honestly, I'll simply stop reading mailing list and go on my own.
> > 
> > First of all, this is exactly the kind of attitude I was talking about,
> > which we see *EXTREMELY FREQUENTLY* from Kali users especially.  If you
> > behave like this on any of the Debian IRC channels, you will get no help.
> I am not a Kali user.
> 
> > 
> > Second, no, not all third-party software makes your system unsupportable.
> > But *packages* that are installed from other distributions most certainly
> > do.
> > 
> 
> Why would a package I get from a git repository be supportable but a
> package I save some packaging time and get from another source (Kali,
> Ubuntu for example) would become unsupportable ?

Ahem.

Installing a software thingy in /opt or /usr/local or such
limits the damage to "it doesn't work, but the system as a whole
works otherwise". 

Adding a package repository or installing a random .deb file off
the Internet can change arbitrary things in your system, and
stuff that you didn't think you were changing can suddenly stop
working. That's extremely difficult to debug.


> So you are telling me that support stop as soon I build myself a custom
> package but if I build software and put it outside the packaging system,
> it's supportable ?

Oh, no, no no no.

There is no support for anything!

But all of us volunteers are willing to help out, from each
according to their abilities, to each according to the random
factors of the universe.

> And if I build myself a package, for example I packaged all my roms used
> for gaming into a deb file, this way it's easy to install and I use a
> repository on my local network. By doing it this way, my gf who already
> does her updates can also update the pack of roms I got.
> So this is bad and make me loose community support ?

No, because see above: there's no support.

The question is, what can you do to maximize the chances of
someone helping you?

> I feel like people just feel good telling others "You are wrong" so they
> can feel "right".

In this case, you are mostly wrong. People are telling you that
you're doing it the wrong way because their experience (and
mine) is that they have spent far too much of their own time
trying to debug problems that they cannot possibly reproduce,
because you have a version of libinsidious that nobody else has.

-dsr-

[toc] | [prev] | [next] | [standalone]

#235404

[Multipart message — attachments visible in raw view] — view raw

On 2021-05-19 2:29 p.m., Dan Ritter wrote:
> Polyna-Maude Racicot-Summerside wrote: 
>>
>> On 2021-05-19 2:01 p.m., Greg Wooledge wrote:
>>> On Wed, May 19, 2021 at 01:29:44PM -0400, Polyna-Maude Racicot-Summerside wrote:
>>>> Now if what you are telling me is :
>>>> That all software that I may run on my Linux box that are not inside 
the
>>>> Debian repository will make my system a "frankendebian" and will entitle
>>>> myself to be called off-topic and not worth having my message read, then
>>>> honestly, I'll simply stop reading mailing list and go on my own.
>>>
>>> First of all, this is exactly the kind of attitude I was talking about,
>>> which we see *EXTREMELY FREQUENTLY* from Kali users especially.  If you
>>> behave like this on any of the Debian IRC channels, you will get no help.
>> I am not a Kali user.
>>
>>>
>>> Second, no, not all third-party software makes your system unsupportable.
>>> But *packages* that are installed from other distributions most certainly
>>> do.
>>>
>>
>> Why would a package I get from a git repository be supportable but a
>> package I save some packaging time and get from another source (Kali,
>> Ubuntu for example) would become unsupportable ?
> 
> Ahem.
> 
> Installing a software thingy in /opt or /usr/local or such
> limits the damage to "it doesn't work, but the system as a whole
> works otherwise". 
> 

I don't know how many package you have developed or what's you
background but :

The packaging system make sure no one write over others file.
Installing a software in /opt doesn't prevent it from trashing files in /etc

Only thing it does is make it simple when you get some problem regarding
library compatibility because it come after /usr/lib in the list of
folder checked by the linker.

> Adding a package repository or installing a random .deb file off
> the Internet can change arbitrary things in your system, and
> stuff that you didn't think you were changing can suddenly stop
> working. That's extremely difficult to debug.
> 
> 

I already know not to install untrusted software on my computer.

You are getting far from what I was talking about.

I don't install .deb from the "internet".

I build my own software package when needed. I look over at the source
code, the scripts and everything else.

>> So you are telling me that support stop as soon I build myself a custom
>> package but if I build software and put it outside the packaging system,
>> it's supportable ?
> 
> Oh, no, no no no.
> 
> There is no support for anything!
> 
I know that there's no support.
My wording was wrong.

> But all of us volunteers are willing to help out, from each
> according to their abilities, to each according to the random
> factors of the universe.
> 
>> And if I build myself a package, for example I packaged all my roms used
>> for gaming into a deb file, this way it's easy to install and I use a
>> repository on my local network. By doing it this way, my gf who already
>> does her updates can also update the pack of roms I got.
>> So this is bad and make me loose community support ?
> 
> No, because see above: there's no support.
> 
> The question is, what can you do to maximize the chances of
> someone helping you?
> 
>> I feel like people just feel good telling others "You are wrong" so they
>> can feel "right".
> 
> In this case, you are mostly wrong. People are telling you that
> you're doing it the wrong way because their experience (and
> mine) is that they have spent far too much of their own time
> trying to debug problems that they cannot possibly reproduce,
> because you have a version of libinsidious that nobody else has.
> 
> -dsr-
> 

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

[toc] | [prev] | [next] | [standalone]

#235405

Polyna-Maude Racicot-Summerside wrote: 
> 
> 
> On 2021-05-19 2:29 p.m., Dan Ritter wrote:
> > Polyna-Maude Racicot-Summerside wrote: 
> 
> I already know not to install untrusted software on my computer.

We're all happy about that. Not everyone is as good about that
as you are.

This is not about you. This is about why people on this mailing
list don't want to help people who do things badly.

But there's no rule about it. No law. People are free to help
you or not, even if you have built a system from your own
compiler chain and wrote an /etc/debian-version by hand.


-dsr-

[toc] | [prev] | [next] | [standalone]

#235414

On Wednesday 19 May 2021 14:29:15 Dan Ritter wrote:

> Polyna-Maude Racicot-Summerside wrote:
> > On 2021-05-19 2:01 p.m., Greg Wooledge wrote:
> > > On Wed, May 19, 2021 at 01:29:44PM -0400, Polyna-Maude 
Racicot-Summerside wrote:
> > >> Now if what you are telling me is :
> > >> That all software that I may run on my Linux box that are not
> > >> inside the Debian repository will make my system a
> > >> "frankendebian" and will entitle myself to be called off-topic
> > >> and not worth having my message read, then honestly, I'll simply
> > >> stop reading mailing list and go on my own.
> > >
> > > First of all, this is exactly the kind of attitude I was talking
> > > about, which we see *EXTREMELY FREQUENTLY* from Kali users
> > > especially.  If you behave like this on any of the Debian IRC
> > > channels, you will get no help.
> >
> > I am not a Kali user.
> >
> > > Second, no, not all third-party software makes your system
> > > unsupportable. But *packages* that are installed from other
> > > distributions most certainly do.
> >
> > Why would a package I get from a git repository be supportable but a
> > package I save some packaging time and get from another source
> > (Kali, Ubuntu for example) would become unsupportable ?
>
> Ahem.
>
> Installing a software thingy in /opt or /usr/local or such
> limits the damage to "it doesn't work, but the system as a whole
> works otherwise".
>
> Adding a package repository or installing a random .deb file off
> the Internet can change arbitrary things in your system, and
> stuff that you didn't think you were changing can suddenly stop
> working. That's extremely difficult to debug.
>
> > So you are telling me that support stop as soon I build myself a
> > custom package but if I build software and put it outside the
> > packaging system, it's supportable ?
>
> Oh, no, no no no.
>
> There is no support for anything!
>
> But all of us volunteers are willing to help out, from each
> according to their abilities, to each according to the random
> factors of the universe.
>
> > And if I build myself a package, for example I packaged all my roms
> > used for gaming into a deb file, this way it's easy to install and I
> > use a repository on my local network. By doing it this way, my gf
> > who already does her updates can also update the pack of roms I got.
> > So this is bad and make me loose community support ?
>
> No, because see above: there's no support.
>
> The question is, what can you do to maximize the chances of
> someone helping you?
>
> > I feel like people just feel good telling others "You are wrong" so
> > they can feel "right".
>
> In this case, you are mostly wrong. People are telling you that
> you're doing it the wrong way because their experience (and
> mine) is that they have spent far too much of their own time
> trying to debug problems that they cannot possibly reproduce,
> because you have a version of libinsidious that nobody else has.
>
> -dsr-

+10, or more. Thanks for pointing this out, Dan. Its a point too often 
missed in the usual "I've been insulted" responses seen here.

This is a distraction, but illustrates the problem:

To put the chances of screwing up the system totally by installing 
something packaged to run on a different system to the N! of the number 
of bytes a diff command comparing a properly built package for your fav 
system, with the same package from another system that just happens to 
use the same package manager. Then check to see if the calculator you 
and I can afford says 1.711224524E98 for a 69! entry. Numbers above 69 
need a 3 digit or on to infinity "ee" number.

Plain and simple, you do not put the result of that build, in a directory 
available to the system. You put it in a sandbox in /opt, or /usr/local, 
or in the case of an AppImage, in your home directory. I do it, but I 
don't recommend it, I'd much druther put it in /opt or usr/local.

Take care, stay safe and well everybody.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#235408

[Multipart message — attachments visible in raw view] — view raw

On Mi, 19 mai 21, 13:29:44, Polyna-Maude Racicot-Summerside wrote:
> 
> If this is not a Debian question then tell my what it is ?
> "Why did it was chosen to use the -fPIC option in buildflags.mk on the
> AMD64 platform and will this matter if I take if off because I'm trying
> to build a software that ain't in the repository" (Because software in
> the repository got built so will build).

Build options are likely to be documented in either Debian Policy or 
Developer's Reference.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#235410

[Multipart message — attachments visible in raw view] — view raw

Hi !

On 2021-05-19 3:08 p.m., Andrei POPESCU wrote:
> On Mi, 19 mai 21, 13:29:44, Polyna-Maude Racicot-Summerside wrote:
>>
>> If this is not a Debian question then tell my what it is ?
>> "Why did it was chosen to use the -fPIC option in buildflags.mk on the
>> AMD64 platform and will this matter if I take if off because I'm trying
>> to build a software that ain't in the repository" (Because software in
>> the repository got built so will build).
> 
> Build options are likely to be documented in either Debian Policy or 
> Developer's Reference.
> 
Thanks for the answer.
But my question was more of a example than something else.

Anyway, yes Debian has the most wonderful documentation you can find for
ANY opensource project on this planet (and possibly the most wonderful
of all our known universe and one to be discovered).

Thanks

> Kind regards,
> Andrei
> 

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web