wifi: désactiver 5ghz Intel 7260

[jérémy prego]

bonjour,

parfois, j'aimerai désactiver le 2,4 ou le 5ghz selon l'endroit où je me 
trouve, de façon simple. je précise que je n'ai pas accès au routeur. en 
cherchant sur internet j'ai bien vu une commande du genre iwconfig wlan0 
freq 5G mais ça donne rien chez moi, sauf une erreur du driver.


est-ce possible, déjà ?

je précise que c'est pour le cas ou le même SSID est sur les deux réseaux

merci pour vos astuces

jerem

Re: pen testing beginner

[David Christensen]

On 10/29/2016 11:50 AM, emetib wrote:
> have been a linux only person since before 2000 (late 2.2 early 2.4
> kernels), yet haven't done much with it in the last ten years. ...

> i'm looking at getting back into it and into pen
> testing.

I assume you mean penetration testing.  Given that computers and
networks are built from many hardware, firmware, and software work
products, I would expect that there are specialties.  It might help to
pick one, and then find the knowledge and skill dependencies.


> from what i have been reading lately i'm going to have to know quite
> a bit about a couple of different things that i didn't jump to deep
> into before, programming and networking especially. ...

> i have given myself a four year window on this learning cycle and am
curious about going about it. ...

> please just give advice and not right or wrong opinions on what i
> maybe trying to do with my options and if i should actually take some
> classes to augment my self learning.

If you are serious about this, go get yourself a degree in computer
science.  I preferred and recommend the old-fashioned university
approach -- professors, planned sequence of courses, classrooms, labs,
textbooks, homework, projects, and especially the camaraderie of other
students.


David

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[rhkramer]

On Saturday, October 29, 2016 07:00:02 PM Brian wrote:
> What happened to curiosity?

Curiosity is a function of available resources, among them time.

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Brian]

On Sat 29 Oct 2016 at 16:28:24 -0400, rhkra...@gmail.com wrote:

> On Saturday, October 29, 2016 03:53:21 PM Brian wrote:
> > On Sat 29 Oct 2016 at 15:28:14 -0400, rhkra...@gmail.com wrote:
> > > On Saturday, October 29, 2016 08:54:59 AM Reco wrote:
> > > > On Sat, 29 Oct 2016 08:16:18 -0400
> > > > 
> > > > rhkra...@gmail.com wrote:
> > > > > I'm not the OP or anybody that has participated in this thread so
> > > > > far.
> > > > 
> > > > [1] tells me otherwise, for the 'participation' part. I take it that
> > > > this e-mail I'm replying to is shared among several people, then?
> > > 
> > > Oops, sorry, you're right--somehow I forgot all about that.
> > > 
> > > > I believe you're missing the point here. The page in question is not
> > > > supposed to provide information on mounting anything as a *key piece*
> > > > in the first place due to very nature of the topic the page describes.
> > > > 
> > > > But since such information is in there for some reason, and it's
> > > > covering *both* mounting and unmounting in a compact enough form - it
> > > > can be used as an example for mounting and unmounting also.
> > > 
> > > If I say anything, I'll just be belaboring the point further, so I won't.
> > > Or, I will, I was only trying to support the OP who said there was
> > > nothing of
> > 
> > What would you have wanted to see? Please be detailed. The OP is
> > unlikely to respond, so we are relying on you.
> 
> I'll have to think about that--maybe nothing--my first thoughts are that:
>* I agree that page didn't need to go any deeper,
>* but I also agree with the comment the OP made, something like there was 
> nothing substantial about pmount on that page--he apparently (or might have) 
> tried one of the other two alternatives, and failing that, have asked for 
> more 
> help, as he did...

There are very few wiki pages which are so completely self-contained
that one does not have to consult outside sources. It should not be
expected that they be complete in every aspect. Anything not deemed
substantial can be looked up elsewhere, starting, perhaps, with a man
page on a local machine.

What happened to curiosity?

-- 
Brian.
 

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Brian]

On Sat 29 Oct 2016 at 23:23:52 +0300, Reco wrote:

> On Sat, 29 Oct 2016 19:15:53 +0100
> Brian  wrote:
> 
> > I wish you had addressed the "equal exposure" question. Desktops are not
> > the only environments in town. Leaving non-policykit users out in the
> > cold is not an option.
> 
> True, that does not look good at all. But why bother listing udisks2
> which is using PolicyKit then?

In the light of previous points I think there is a non-sequiteur in
there somwhere.
 
> Besides, in modern Debian it takes a certain amount of skill and
> determination *not* to use PolicyKit ;)

Maybe. Nothing to do with whether policykit is on a machine or not, of
course.

> > It doesn't come down to that; using a desktop filemanager is just one of
> > the alternatives. One could equally well ask why it is has to mentioned
> > when there is
> > 
> >  > Install pmount, udevil or udisks2 and use one . 
> 
> Indeed. All this confusion could be avoided by simple 'please mount the
> USB stick to this mountpoint'. Again, the page describes rather
> advanced topic.

As said, a rewrite is in the offing. The reality is that all operations
should be with root privileges.
 
> > Providing a range of advice for a range of people isn't exactly easy in
> > all situations. Advice on installing a wifi kernel module is easy -
> > there is only one for each chipset.
> 
> I honestly wish that this was true. Sadly, there's Broadcom, see [1]
> for the gory details.

There are always exceptions.

> > A page on pmount is a little harder because it is a moving target.
> 
> I honestly lost you here. oldstable, stable, testing and even sid have
> the same upstream version of pmount - 0.9.23, dated 2010.

They do indeed. Six years. Do you get the feeling it is getting on for
unmaintained. (And a wiki page with HAL on it! I ask you). But software
changes. Then wiki pages change. 

> > (The link you gave has out-of-date info on HAL). Anything more 
> > complex can always be criticised as time moves on.
> 
> The page itself is somewhat outdated, true. Someone should cleanup that
> obsolete hal reference.

Don't look at me.

> > But your sort of constructive criticism is valuable.
> 
> You're welcome, I guess.
> 
> > You are getting carried away here. Both are for *automatically* mounting
> > and unmounting removable media, which is not a focus for the task.
> > 
> > There is no sign of supermount in stable or unstable.
> 
> True. That's something that I missed.

We all miss something.

> > As little as possible should be done as root is a good principle.
> 
> mount(2) system call is a privileged one regardless of the tool used.
> Hence a root intervention in one form or the other is needed.
> 
> Whenever such privilege escalation is done by trusted daemon (udisks2),
> or by hand (su, sudo) for the purposes of mounting and unmounting is not
> relevant. Assuming, for the sake of simplicity, that all implementations
> of privilege escalation (su, sudo, policykit, trusted suid binaries
> such as pmount) are free of security bugs.
> 
> If it was desirable to exclude root intervention whenever possible in
> this task - the page in question would suggest fusefat instead.

Something to consider and test. Thanks.
 
> > C'mon; pointing out a typo! This is unworthy of you, even as an aside.
> 
> Disregard the typo comment then as it was not pointed to the article
> quality. Not all mount(8) invokations require root, that was the point.
> 
> > Mounting and unmounting are not really a problem. Users and root can
> > easily do these. But, as far as I can see, only someone with root
> > privileges can use dd, cfdisk, fdisk and mkfs.vfat with a removable
> > device. I'd like to be wrong.
> 
> This is a common myth that I'll debunk gladly.
> 
> Image copying (dd or any other tool) merely requires ability to write
> to a block device. Such permissions on removable media should be
> provided to any current console user by logind (or ConsoleKit if we
> still need to think about wheezy), or a good old-fashioned
> 'floppy' (any group name will do) group and a custom udev rule (as of
> jessie).
> 
> Creating any filesystem on a removable media's partition merely requires
> the same.

Since you wrote this, hundreds of people using GNOME have popped a USB
stick into their machines and typed

  dd if=/dev/zero of=/dev/

Those who didn't get

  dd: failed to open 'dev/'

will be along soon to report success and explain why.

The floppy group + a udev rule is a Wheezy thing. Not suitable for a
wiki relating to a current Debian.

-- 
Brian.

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[deloptes]

Reco wrote:

> 1) Python as a dependency, again. Wait, haven't we install one already
> with 'hplip-data'? Some python modules too, yet the package does not
> contain a single python script (see pt 6).

IMO python should be banned from real development.
I dislike the new KDE most of all because they relay on python too much.
Open source - no any kind of standard ... and this is the fastest way to
make something bad out of pretty every idea.

Also your other points are really good. Especially KDE dependencies ... you
end up installing all kind of unwanted/unnecessary software. I was
wondering at some point of time ... are those developers based in Peru,
where c***in is legal and they take  too much ... unbelievable. Also they
got ressistent to any opposite opinion ... much like the so called
democrats in the US. I'm just wondering what's going on with the people on
this world ... and come to the conclusion that a lot of them are crazy -
literally - psychopats, sociopaths and any kind of ***paths. Perhaps I'm
getting old, but this can't be the only reason, as others feel/think the
same as I do ... so Reco, don't worry - the only way is to patiently push
your ideas or find people like you and work together.
We can not stop the wave of idiocracy that takes over via face book, twitter
and all of the kind unnecessary gossip channels.
What I do is trying to make things work for me and perhaps help this way
others, which is the basic of open source contributions.
I however do not expect that this nonsense will stop. I expect the opposite
looking at the 20-30y old. In 10y the mess will be complete.

regards

Re: WiFi works during install, not after

[Lisi Reisz]

On Saturday 29 October 2016 20:17:03 Brian wrote:
> On Sat 29 Oct 2016 at 17:26:38 +0100, Lisi Reisz wrote:
> > On Saturday 29 October 2016 15:30:51 Carl Fink wrote:
> > > On 10/29/2016 10:21 AM, Lisi Reisz wrote:
> > > > On Wednesday 26 October 2016 18:24:04 Carl Fink wrote:
> > > >> Thanks.
> > > >>
> > > >> I actually remember seeing it now that you remind me.
> > > >>
> > > >> Define "desktop". I set up Xfce4.
> > > >
> > > > But did you do so DURING INSTALLATION?  So the complete question,
> > > > which you have still not answered in its entirety, was:
> > > > "Did you install a desktop during the installation?"
> > > >
> > > > Desktop is as defined in tasksel during the installation.  (Tasksel
> > > > uses the actual word "desktop")
> > > >
> > > > The "during", which you have continued to ignore, is important and
> > > > could be the crux of your problem.
> > >
> > > Quibble: not "ignore". Fail to understand the question. Functionally
> > > thea
>
> What was there not to understand. To quote:
>   > Did you install a desktop *during* the installation?
>
> The "during" is highlighted. It's an easy enough question to answer. How
> many mails was it before we got a definitive answer?
>
> > > same, intentionality different.
> > >
> > > Yes, during installation.
>
> Not that it will alter the OP's point of view: the functionality of
> installing Xfce from the installer is not the same as installing from a
> running system.
>
> > Right, so that is not the problem.  I'm afraid I stand by my ignore - you
> > clearly do understand "during", so you were ignoring it!! ;-)
> >
> > Did you install the laptop stuff during installation?  If not, try
> > rerunning tasksel (it is a command that is available and seems not to
> > require root) and making sure that you have got the laptop stuff as well
> > as the desktop stuff. I don't know what you do about the fact that you
> > have not at this moment got running wi-fi, which you did have last time
> > you ran tasksel, but run it anyway and see if it helps.
>
> Running tasksel will not repeat or replicate the d-i environment.

No, but there might be a/some package(s) missing that is/are crucial to wi-fi, 
that a running of tasksel would install.  I should have thought that it was 
worth a try.  

You know that I am no wi-fi guru, but packages that are crucial to wi-fi are 
bound to be included in a collection of software tailored for laptops.

Lisi

> He hadn't got running wi-fi because he had cocked something up. Maybe he
> has it now,

Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)

[Reco]

Hi.

On Sat, 29 Oct 2016 20:36:27 +0100
Brian  wrote:

> On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote:
> 
> > Hi.
> > 
> > On Sat, 29 Oct 2016 19:54:27 +0200
> > deloptes  wrote:
> > 
> > > Reco wrote:
> > > 
> > > > So basically you're proposing to force the user to install GTK3 (with
> > > > both C and C++ bindinds) just to install pulseaudio.
> > > > 
> > > > There are reasons that this distribution is called Debian, not
> > > > You-favorite-enterprisey-tangled-dependency-mess, and one of those
> > > > reasons is a careful placement of dependencies.
> > > > 
> > > > Reco
> > > 
> > > Ric didn't say he proposes. He said "I think" which is personal opinion. I
> > > think nowdays it is getting a big problem understanding each other and I
> > > think it is sad, because we are misinterpreting what the other say which 
> > > is
> > > equivalent to not hearing.
> > 
> > My apologies to Ric, you and any other maillist participant just in
> > case.
> 
> A sentence beginning "I think you should." is practically equivalent
> to "I propose you should..". So Ric did propose something. Proposing
> or thinking is always a personal opinion.
> 
> You shouldn't have backed down.

I don't consider an apology (including just-in-case ones) to be a
variation of lost argument. I consider an apology as a sign of
courtesy, no more, no less.


> > Oh, and don't get me started on the way they package hplip.
> 
> Please do. What is wrong with the packaging of hplip?

I won't speak of stretch and sid, as these branches of Debian
distribution don't interest me in this regard so far.

The task itself is simple - one (may be two for the redundancy)
centralized print-servers with arbitrary number of clients (without
any CUPS or HPLIP). Several HP printers, because they bought the stuff.

What's needed? A small amount of packages providing needed CUPS
filters, backends and PPDs. The CUPS itself, of course.

What do they give us in Debian instead? An enterprisey tangled mess.

'hplip' itself, and it's direct dependencies 'hplip-data' and
'printer-driver-hpcups'.

There's also 'hplip-gui' with the bunch of worthless (for the
print-server) GUI tools. Oh, and python-qt4 as a dependency and a half
of KDE with it as a result, not a small achievement for the package of
the size of 88k.

Let's continue with 'hplip-data' as its list of dependencies is smaller.
For the lazy of us, package description states 'This package
contains data files and PPDs for the HP Linux Printing and Imaging
System'. Apparently said 'data files' are in fact python scripts put
into this package for some bizarre reason, as package brings you python
installation immediately.

Next, the big winner, 'hplip'. Highlight points include:

1) Python as a dependency, again. Wait, haven't we install one already
with 'hplip-data'? Some python modules too, yet the package does not
contain a single python script (see pt 6).

2) wget as a dependency. Included for the sole purpose of acquiring
non-free blobs from openprining.org by /usr/bin/hp-firmware (see pt 6),
yet the package somehow belongs in 'main'.

3) policykit-1 as a dependency. How exactly it's required for the
actual printing done by CUPS invoking HPLIP filters
(executables /usr/lib/cups/filter/) and backends
(executables /usr/lib/cups/backend/)?
Hint - it's not. But a certain python script (see pt 6) apparently
does.

4) avahi-daemon as Recommends. Apparently it's considered so important
that they recommend it again (CUPS has the same Recommend). Kind of
surprised not to see it as Depends.

5) Aforementioned backends. Worth mentioning as another part of the
puzzle actually related to the printing (filters) resides in
'printer-driver-hpcups' (which is by itself is ok). Apparently because
reasons.

6) A bunch of symlinks to assorted python scripts from 'hplip-data',
note again that it's 'hplip' that contains all those python script
dependencies, not 'hplip-data'.

Things have improved somewhat since wheezy (they didn't provide
'printer-driver-hpcups' back then), but it's only 'somewhat'.

Reco

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[deloptes]

Brian wrote:

> On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote:
> 
>> Hi.
>> 
>> On Sat, 29 Oct 2016 19:54:27 +0200
>> deloptes  wrote:
>> 
>> > Reco wrote:
>> > 
>> > > So basically you're proposing to force the user to install GTK3 (with
>> > > both C and C++ bindinds) just to install pulseaudio.
>> > > 
>> > > There are reasons that this distribution is called Debian, not
>> > > You-favorite-enterprisey-tangled-dependency-mess, and one of those
>> > > reasons is a careful placement of dependencies.
>> > > 
>> > > Reco
>> > 
>> > Ric didn't say he proposes. He said "I think" which is personal
>> > opinion. I think nowdays it is getting a big problem understanding each
>> > other and I think it is sad, because we are misinterpreting what the
>> > other say which is equivalent to not hearing.
>> 
>> My apologies to Ric, you and any other maillist participant just in
>> case.
> 
> A sentence beginning "I think you should." is practically equivalent
> to "I propose you should..". So Ric did propose something. Proposing
> or thinking is always a personal opinion.
> 
> You shouldn't have backed down.
> 

Come on Brian, we don't need "wars". Exactly the point is the personal
opinion. Ric says "I think it should". Roco takes it as proposal. Perhaps
my English is not that good, but I don't take a personal opinion "I think
it should" as proposal. In his epistemic world this package is better
requireing the other package, but in the real world it just suggest.
So lets agree that "suggests" is the better solution for this and that
reason and leave it there.

>> Still, I've seen where this road can take a perfectly good package.
>> 
>> First example being openjdk-7-jre-headless. After a certain DSA update
>> about a year ago it started to depend on libpulse0 (because reasons,
>> apparently), and boom - a *headless* java install bring about one third
>> of X with it. Kind of depends the whole purpose of package from a
>> certain perspective - as package description explicitly refers 'non GUI
>> Java programs'.
>> 
>> Second example being libvirt-daemon-system, introduced in jessie, which
>> started to depend on policykit-1, because (see #768376) from
>> the POV of the maintainer of the package - absolutely nobody (bug
>> report states 95% actually) uses libvirt without virt-manager, and
>> virt-manager breaks somehow without PolicyKit.
>> 

I completely agree with Reco on all the arguments also from his previous
mail. I'm glad that not all "suggestions" are implemented and made
available to the public.
I also hate it when a simple program pulls in a lot of unrealted and
unwanted software, just because some developer did not define dependencies
in a proper way. However Reco is better off raising this issue with the
maintainers and developers. I have few custom build packages that suite my
personal needs. 
Ah and I froze policy kit because later versions were not providing what I
need.
So yes I agree with Reco except for the way he put it forward.
I think Ric should not propose pulse depending on the graphical frontend. We
just have to know that this is available and useful if one has X and some
kind of desktop installed.
I wish that pavucontrol had various implementations aside gtk, but we all
have gtk installed -no? At least because of firefox or some other program.

>> Oh, and don't get me started on the way they package hplip.
> 
> Please do. What is wrong with the packaging of hplip?

Yes indeed ... but perhaps in another thread.

regards

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[rhkramer]

On Saturday, October 29, 2016 03:53:21 PM Brian wrote:
> On Sat 29 Oct 2016 at 15:28:14 -0400, rhkra...@gmail.com wrote:
> > On Saturday, October 29, 2016 08:54:59 AM Reco wrote:
> > > On Sat, 29 Oct 2016 08:16:18 -0400
> > > 
> > > rhkra...@gmail.com wrote:
> > > > I'm not the OP or anybody that has participated in this thread so
> > > > far.
> > > 
> > > [1] tells me otherwise, for the 'participation' part. I take it that
> > > this e-mail I'm replying to is shared among several people, then?
> > 
> > Oops, sorry, you're right--somehow I forgot all about that.
> > 
> > > I believe you're missing the point here. The page in question is not
> > > supposed to provide information on mounting anything as a *key piece*
> > > in the first place due to very nature of the topic the page describes.
> > > 
> > > But since such information is in there for some reason, and it's
> > > covering *both* mounting and unmounting in a compact enough form - it
> > > can be used as an example for mounting and unmounting also.
> > 
> > If I say anything, I'll just be belaboring the point further, so I won't.
> > Or, I will, I was only trying to support the OP who said there was
> > nothing of
> 
> What would you have wanted to see? Please be detailed. The OP is
> unlikely to respond, so we are relying on you.

I'll have to think about that--maybe nothing--my first thoughts are that:
   * I agree that page didn't need to go any deeper,
   * but I also agree with the comment the OP made, something like there was 
nothing substantial about pmount on that page--he apparently (or might have) 
tried one of the other two alternatives, and failing that, have asked for more 
help, as he did...

Re: Intel Corporation HD Graphics 510 on GNOME

[Felix Miata]

Samuel Bächler composed on 2016-10-29 21:56 (UTC+0200):


I have got a graphics adapter that is somehow integrated on the
motherboard. [1] On this hardware I can use KDE but no GNOME. When
installing GNOME I get the error message 'Oh no! Something has gone wrong.
A problem has occurred and the system can't recover. Please contact a
system administrator'. Is there a known problem with GNOME and my graphics
adapter?


Is this with Debian 8 Jessie or Debian 7 Wheezy?


[1]



'lspci' shows in particular 'Intel Corporation HD Graphics 510'. 'dmidecode
--type baseboard' shows in particular 'Manufacturer: FUJITSU' and 'Product
Name: D3400-B1'.


NAICT from Googling, Jessie's 3.16 kernel is too old to fully support Skylake 
(August 2105 release) CPU features required by Gnome, so you need a kernel 
newer than 4.1 (June 2015), and/or Stretch (currently on 4.7).

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Reco]

Hi.

On Sat, 29 Oct 2016 19:15:53 +0100
Brian  wrote:

> On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote:
> 
> > On Sat, 29 Oct 2016 15:09:09 +0100
> > Brian  wrote:
> > 
> > > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:
> > > 
> > > > On Sat, 29 Oct 2016 08:16:18 -0400
> > > > rhkra...@gmail.com wrote:
> > > > 
> > > > > I'll say that the wiki page gave no hint as to which of the three 
> > > > > options to 
> > > > > install, or any hint that one might work better than another.
> > > > 
> > > > The page is describing 'Producing an automated install of a Debian
> > > > operating system from a USB stick', to quote it. For such an advanced
> > > > task it can be safely assumed IMO that the person who's implementing the
> > > > instruction is familiar with the basic concepts of a 'file system' or
> > > > 'mounting'.
> > > 
> > > The question of providing guidance on which of the three tools to use is
> > > an interesting one. As far as possible a wiki page like this one should
> > > stick to facts and technical matters; venturing into the area of opinion
> > > isn't the way to go, IMO. Do any of these tools have a distinct
> > > technical advantage for the purpose of installing GRUB is the question
> > > to ask and answer? If the answer is "no" don't they deserve equal
> > > exposure?
> > 
> > No advantage that I'm aware of. In fact, the whole paragraph could be
> > shortened to already existing text:
> > 
> > If you are working within one of the desktop environments it is very
> > likely the mounting can be done from he file manager which comes with
> > it. This is because udisks2 will be on the system. A label will
> > possibly be used for the mount point.
> 
> I wish you had addressed the "equal exposure" question. Desktops are not
> the only environments in town. Leaving non-policykit users out in the
> cold is not an option.

True, that does not look good at all. But why bother listing udisks2
which is using PolicyKit then?

Besides, in modern Debian it takes a certain amount of skill and
determination *not* to use PolicyKit ;)


> > > The tools exist and all can be assumed to work.  The choice of which one
> > > to use is up to the user. For many users a couple of clicks on a desktop
> > > will get the stick mounted; others might like the challenge of using a
> > > new tool. 
> > 
> > My point exactly. Why bother naming all these tools if it all comes down
> > to "you might use your file manager to do this part for you as well"?
> 
> It doesn't come down to that; using a desktop filemanager is just one of
> the alternatives. One could equally well ask why it is has to mentioned
> when there is
> 
>  > Install pmount, udevil or udisks2 and use one . 

Indeed. All this confusion could be avoided by simple 'please mount the
USB stick to this mountpoint'. Again, the page describes rather
advanced topic.


> Providing a range of advice for a range of people isn't exactly easy in
> all situations. Advice on installing a wifi kernel module is easy -
> there is only one for each chipset.

I honestly wish that this was true. Sadly, there's Broadcom, see [1]
for the gory details.


> A page on pmount is a little harder because it is a moving target.

I honestly lost you here. oldstable, stable, testing and even sid have
the same upstream version of pmount - 0.9.23, dated 2010.


> (The link you gave has out-of-date info on HAL). Anything more 
> complex can always be criticised as time moves on.

The page itself is somewhat outdated, true. Someone should cleanup that
obsolete hal reference.


> But your sort of constructive criticism is valuable.

You're welcome, I guess.


> > > A few might say - "Hey, interesting, never knew about that;
> > > I'll give it a go". And then go on to use it in another context.
> > 
> > True, but why stop here? Author(s?) of the page might mention usbmount
> > and supermount as well.
> 
> You are getting carried away here. Both are for *automatically* mounting
> and unmounting removable media, which is not a focus for the task.
> 
> There is no sign of supermount in stable or unstable.

True. That's something that I missed.


> > > > It can be argued (again IMO) that the 3 tools proposed are not the best
> > > > ones available for the task, or downright redundant due to availability
> > > > of mount(8), but all three mentioned tools are in fact are links to [2].
> > > > Broken ones (for me at least), but they are links to manpages for the
> > > > mentioned tools. Surely a manpage can be viewed as a suitable source of
> > > > hints you're referring to.
> > > 
> > > mount is a root-only tool; the others aren't. Need I say more?
> > 
> > Yes, I believe you do.
> 
> As little as possible should be done as root is a good principle.

mount(2) system call is a privileged one regardless of the tool used.
Hence a root intervention in one form or the other is needed.

Whenever such privilege escalation is done by trusted daemon 

Re: Update to Sid, and cannot compile Nvidia module; PIC mode?

[Will]

Hey Dirk.  Thank you!  That worked, it compiles!  And I don't have to get
my hands dirty with a patch. :)

On Fri, Oct 28, 2016 at 9:11 PM, Dirk Laebisch  wrote:

> > Anyone else run into this on Sid very recently?  Any hints or pointers?
>
> Yup.
> Providing some compile flags in:
> /usr/src/linux/Makefile
> around line 614 fixed it for me.
>
>  614 # force no-pie for distro compilers that enable pie by default
>  615 KBUILD_CFLAGS += $(call cc-option, -fno-pie)
>  616 KBUILD_CFLAGS += $(call cc-option, -no-pie)
>  617 KBUILD_AFLAGS += $(call cc-option, -fno-pie)
>  618 KBUILD_CPPFLAGS += $(call cc-option, -fno-pie)
>
> After that, dkms succeeded and no further problems ... so far.
>
> Regards
> Dirk
>
>

Intel Corporation HD Graphics 510

[Samuel Bächler]

Dear All

I have got a graphics adapter that is somehow integrated on the
motherboard. [1] On this hardware I can use KDE but no GNOME. When
installing GNOME I get the error message 'Oh no! Something has gone wrong.
A problem has occurred and the system can't recover. Please contact a
system administrator'. Is there a known problem with GNOME and my graphics
adapter?

Regards,
Sam

[1]

'lspci' shows in particular 'Intel Corporation HD Graphics 510'. 'dmidecode
--type baseboard' shows in particular 'Manufacturer: FUJITSU' and 'Product
Name: D3400-B1'.

Intel Corporation HD Graphics 510 on GNOME

[Samuel Bächler]

Dear All

I have got a graphics adapter that is somehow integrated on the
motherboard. [1] On this hardware I can use KDE but no GNOME. When
installing GNOME I get the error message 'Oh no! Something has gone wrong.
A problem has occurred and the system can't recover. Please contact a
system administrator'. Is there a known problem with GNOME and my graphics
adapter?

Regards,
Sam

[1]

'lspci' shows in particular 'Intel Corporation HD Graphics 510'. 'dmidecode
--type baseboard' shows in particular 'Manufacturer: FUJITSU' and 'Product
Name: D3400-B1'.

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Brian]

On Sat 29 Oct 2016 at 15:28:14 -0400, rhkra...@gmail.com wrote:

> On Saturday, October 29, 2016 08:54:59 AM Reco wrote:
> > On Sat, 29 Oct 2016 08:16:18 -0400
> > rhkra...@gmail.com wrote:
> 
> > > I'm not the OP or anybody that has participated in this thread so far.
> > 
> > [1] tells me otherwise, for the 'participation' part. I take it that
> > this e-mail I'm replying to is shared among several people, then?
> 
> Oops, sorry, you're right--somehow I forgot all about that.
> 
> > I believe you're missing the point here. The page in question is not
> > supposed to provide information on mounting anything as a *key piece*
> > in the first place due to very nature of the topic the page describes.
> > 
> > But since such information is in there for some reason, and it's
> > covering *both* mounting and unmounting in a compact enough form - it
> > can be used as an example for mounting and unmounting also.
> 
> If I say anything, I'll just be belaboring the point further, so I won't. Or, 
> I will, I was only trying to support the OP who said there was nothing of 

What would you have wanted to see? Please be detailed. The OP is
unlikely to respond, so we are relying on you.

-- 
Brian/

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Brian]

On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote:

>   Hi.
> 
> On Sat, 29 Oct 2016 19:54:27 +0200
> deloptes  wrote:
> 
> > Reco wrote:
> > 
> > > So basically you're proposing to force the user to install GTK3 (with
> > > both C and C++ bindinds) just to install pulseaudio.
> > > 
> > > There are reasons that this distribution is called Debian, not
> > > You-favorite-enterprisey-tangled-dependency-mess, and one of those
> > > reasons is a careful placement of dependencies.
> > > 
> > > Reco
> > 
> > Ric didn't say he proposes. He said "I think" which is personal opinion. I
> > think nowdays it is getting a big problem understanding each other and I
> > think it is sad, because we are misinterpreting what the other say which is
> > equivalent to not hearing.
> 
> My apologies to Ric, you and any other maillist participant just in
> case.

A sentence beginning "I think you should." is practically equivalent
to "I propose you should..". So Ric did propose something. Proposing
or thinking is always a personal opinion.

You shouldn't have backed down.

> Still, I've seen where this road can take a perfectly good package.
> 
> First example being openjdk-7-jre-headless. After a certain DSA update
> about a year ago it started to depend on libpulse0 (because reasons,
> apparently), and boom - a *headless* java install bring about one third
> of X with it. Kind of depends the whole purpose of package from a
> certain perspective - as package description explicitly refers 'non GUI
> Java programs'.
> 
> Second example being libvirt-daemon-system, introduced in jessie, which
> started to depend on policykit-1, because (see #768376) from
> the POV of the maintainer of the package - absolutely nobody (bug
> report states 95% actually) uses libvirt without virt-manager, and
> virt-manager breaks somehow without PolicyKit.
> 
> Oh, and don't get me started on the way they package hplip.

Please do. What is wrong with the packaging of hplip?

-- 
Brian. 

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[rhkramer]

On Saturday, October 29, 2016 08:54:59 AM Reco wrote:
> On Sat, 29 Oct 2016 08:16:18 -0400
> rhkra...@gmail.com wrote:

> > I'm not the OP or anybody that has participated in this thread so far.
> 
> [1] tells me otherwise, for the 'participation' part. I take it that
> this e-mail I'm replying to is shared among several people, then?

Oops, sorry, you're right--somehow I forgot all about that.

> I believe you're missing the point here. The page in question is not
> supposed to provide information on mounting anything as a *key piece*
> in the first place due to very nature of the topic the page describes.
> 
> But since such information is in there for some reason, and it's
> covering *both* mounting and unmounting in a compact enough form - it
> can be used as an example for mounting and unmounting also.

If I say anything, I'll just be belaboring the point further, so I won't. Or, 
I will, I was only trying to support the OP who said there was nothing of 
significance (or some similar word) (re: pmount) on that page.

Now I'll just hide my head in the sand ;-)

pen testing beginner

[emetib]

hello everyone, 

have been a linux only person since before 2000 (late 2.2 early 2.4 kernels), 
yet haven't done much with it in the last ten years.  when i did do more with 
it, it was a in depth hobby that i enjoyed learning and playing around with.

now that i'm getting up in years and have beat up on my body from being a 
carpenter i'm looking at getting back into it and into pen testing.

from what i have been reading lately i'm going to have to know quite a bit 
about a couple of different things that i didn't jump to deep into before, 
programming and networking especially.

for the programming part--  i can read the manuals and papers on how to make 
programs work and change how they operate with different calls on the cmd line. 
 yet when it comes to writing actual programs, i.e. python, bash (not just 
linking things together in a script, yet writing operational parameters) i 
sometimes run into walls, especially with python.

for the networking part--  i know basically how machines talk to each other and 
basic routing, yet, i don't know about the operational specifications, i.e. osi 
model (which i'm reading now, as to these questions being asked), and other 
networking concepts, packets, priorities, cidr addressing, etc.

basically my questions are, how in depth into both, networking and programming 
am i going to have to delve?  i have given myself a four year window on this 
learning cycle and am curious about going about it.

should i learn one then the other, if so which one first?  should i learn them 
at the same time so that they compliment each other?  should i learn them as i 
read farther into the pen testing books that i have found online?

i started out with mandrake 7 and then jumped into debian (because they had the 
best package management at the time) and have stuck with it since.  i had a 
domain name, with http, https, mail(postfix), dns and such running on my 
server, along with a backup server and a byo firewall(soekris 4511), so i know 
about basic routing principles and how to set up a server to get things working 
properly.  right now i have a dual boot, three partition system going on, linux 
mint debian edition, kali linux, and a shared partition that i keep things on 
that i use in both, music, virtual machines, config files, etc.  i even took a 
linux security class back in the day.  looking at getting another domain name 
and building my home system(s) again.

please just give advice and not right or wrong opinions on what i maybe trying 
to do with my options and if i should actually take some classes to augment my 
self learning.

thank you.
em

Re: WiFi works during install, not after

[Brian]

On Sat 29 Oct 2016 at 17:26:38 +0100, Lisi Reisz wrote:

> On Saturday 29 October 2016 15:30:51 Carl Fink wrote:
> > On 10/29/2016 10:21 AM, Lisi Reisz wrote:
> > > On Wednesday 26 October 2016 18:24:04 Carl Fink wrote:
> > >> Thanks.
> > >>
> > >> I actually remember seeing it now that you remind me.
> > >>
> > >> Define "desktop". I set up Xfce4.
> > >
> > > But did you do so DURING INSTALLATION?  So the complete question, which
> > > you have still not answered in its entirety, was:
> > > "Did you install a desktop during the installation?"
> > >
> > > Desktop is as defined in tasksel during the installation.  (Tasksel uses
> > > the actual word "desktop")
> > >
> > > The "during", which you have continued to ignore, is important and could
> > > be the crux of your problem.
> >
> > Quibble: not "ignore". Fail to understand the question. Functionally thea

What was there not to understand. To quote:

  > Did you install a desktop *during* the installation?

The "during" is highlighted. It's an easy enough question to answer. How
many mails was it before we got a definitive answer?

> > same, intentionality different.
> >
> > Yes, during installation.

Not that it will alter the OP's point of view: the functionality of
installing Xfce from the installer is not the same as installing from a
running system.

> Right, so that is not the problem.  I'm afraid I stand by my ignore - you 
> clearly do understand "during", so you were ignoring it!! ;-)
>
> Did you install the laptop stuff during installation?  If not, try rerunning 
> tasksel (it is a command that is available and seems not to require root) and 
> making sure that you have got the laptop stuff as well as the desktop stuff.  
> I don't know what you do about the fact that you have not at this moment got 
> running wi-fi, which you did have last time you ran tasksel, but run it 
> anyway and see if it helps.

Running tasksel will not repeat or replicate the d-i environment.

He hadn't got running wi-fi because he had cocked something up. Maybe he
has it now,

-- 
Brian

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Reco]

Hi.

On Sat, 29 Oct 2016 19:54:27 +0200
deloptes  wrote:

> Reco wrote:
> 
> > So basically you're proposing to force the user to install GTK3 (with
> > both C and C++ bindinds) just to install pulseaudio.
> > 
> > There are reasons that this distribution is called Debian, not
> > You-favorite-enterprisey-tangled-dependency-mess, and one of those
> > reasons is a careful placement of dependencies.
> > 
> > Reco
> 
> Ric didn't say he proposes. He said "I think" which is personal opinion. I
> think nowdays it is getting a big problem understanding each other and I
> think it is sad, because we are misinterpreting what the other say which is
> equivalent to not hearing.

My apologies to Ric, you and any other maillist participant just in
case.

Still, I've seen where this road can take a perfectly good package.

First example being openjdk-7-jre-headless. After a certain DSA update
about a year ago it started to depend on libpulse0 (because reasons,
apparently), and boom - a *headless* java install bring about one third
of X with it. Kind of depends the whole purpose of package from a
certain perspective - as package description explicitly refers 'non GUI
Java programs'.

Second example being libvirt-daemon-system, introduced in jessie, which
started to depend on policykit-1, because (see #768376) from
the POV of the maintainer of the package - absolutely nobody (bug
report states 95% actually) uses libvirt without virt-manager, and
virt-manager breaks somehow without PolicyKit.

Oh, and don't get me started on the way they package hplip.

So, one must be very careful when wishing for upgrading certain
dependencies.


PS Is it OK to CC you? My e-mail client insists on it for some reason.

Reco

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Brian]

On Sat 29 Oct 2016 at 18:48:11 +0300, Reco wrote:

> On Sat, 29 Oct 2016 15:09:09 +0100
> Brian  wrote:
> 
> > On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:
> > 
> > > On Sat, 29 Oct 2016 08:16:18 -0400
> > > rhkra...@gmail.com wrote:
> > > 
> > > > I'll say that the wiki page gave no hint as to which of the three 
> > > > options to 
> > > > install, or any hint that one might work better than another.
> > > 
> > > The page is describing 'Producing an automated install of a Debian
> > > operating system from a USB stick', to quote it. For such an advanced
> > > task it can be safely assumed IMO that the person who's implementing the
> > > instruction is familiar with the basic concepts of a 'file system' or
> > > 'mounting'.
> > 
> > The question of providing guidance on which of the three tools to use is
> > an interesting one. As far as possible a wiki page like this one should
> > stick to facts and technical matters; venturing into the area of opinion
> > isn't the way to go, IMO. Do any of these tools have a distinct
> > technical advantage for the purpose of installing GRUB is the question
> > to ask and answer? If the answer is "no" don't they deserve equal
> > exposure?
> 
> No advantage that I'm aware of. In fact, the whole paragraph could be
> shortened to already existing text:
> 
> If you are working within one of the desktop environments it is very
> likely the mounting can be done from he file manager which comes with
> it. This is because udisks2 will be on the system. A label will
> possibly be used for the mount point.

I wish you had addressed the "equal exposure" question. Desktops are not
the only environments in town. Leaving non-policykit users out in the
cold is not an option.
 
> > The tools exist and all can be assumed to work.  The choice of which one
> > to use is up to the user. For many users a couple of clicks on a desktop
> > will get the stick mounted; others might like the challenge of using a
> > new tool. 
> 
> My point exactly. Why bother naming all these tools if it all comes down
> to "you might use your file manager to do this part for you as well"?

It doesn't come down to that; using a desktop filemanager is just one of
the alternatives. One could equally well ask why it is has to mentioned
when there is

 > Install pmount, udevil or udisks2 and use one . 

Providing a range of advice for a range of people isn't exactly easy in
all situations. Advice on installing a wifi kernel module is easy -
there is only one for each chipset. A page on pmount is a little harder
because it is a moving target. (The link you gave has out-of-date info
on HAL). Anything more complex can always be criticised as time moves
on.

But your sort of constructive criticism is valuable.

> > A few might say - "Hey, interesting, never knew about that;
> > I'll give it a go". And then go on to use it in another context.
> 
> True, but why stop here? Author(s?) of the page might mention usbmount
> and supermount as well.

You are getting carried away here. Both are for *automatically* mounting
and unmounting removable media, which is not a focus for the task.

There is no sign of supermount in stable or unstable.
 
> > > It can be argued (again IMO) that the 3 tools proposed are not the best
> > > ones available for the task, or downright redundant due to availability
> > > of mount(8), but all three mentioned tools are in fact are links to [2].
> > > Broken ones (for me at least), but they are links to manpages for the
> > > mentioned tools. Surely a manpage can be viewed as a suitable source of
> > > hints you're referring to.
> > 
> > mount is a root-only tool; the others aren't. Need I say more?
> 
> Yes, I believe you do.

As little as possible should be done as root is a good principle.

> The page mentions 'Check the mount point from within the fie manager or
> with the command "mount"' (curious typo btw), rightfully assuming that
> one does not need to be root to do that.

C'mon; pointing out a typo! This is unworthy of you, even as an aside.
 
> The bottom of the page mentions at least one operation that needs to be
> performed as root, so why exactly mounting USB stick as root is somehow
> a bad thing in this context?

Excellent point. This will lead to a rewriting.

The problem at the time was that Wheezy and Jessie behaved differently.
It is mentioned (bug #751892) that root may be necessary. Now Wheezy is
unsupported references to it can go. 

> > The Debian manpages site is broken and awaiting relocation to a new
> > host.
> 
> Here I can only assume that this useful service was available at the
> time that page was written.

Good thinking, Batman. :)
 
> > > >  Of course, 
> > > > until this issue came up, no one may have expected one to work better 
> > > > than 
> > > > another, so then someone reading that page could, quite appropriately, 
> > > > try one 
> > > > and not the others, and assume that there was no more useful 
> > > > information 

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[deloptes]

Reco wrote:

> So basically you're proposing to force the user to install GTK3 (with
> both C and C++ bindinds) just to install pulseaudio.
> 
> There are reasons that this distribution is called Debian, not
> You-favorite-enterprisey-tangled-dependency-mess, and one of those
> reasons is a careful placement of dependencies.
> 
> Reco

Ric didn't say he proposes. He said "I think" which is personal opinion. I
think nowdays it is getting a big problem understanding each other and I
think it is sad, because we are misinterpreting what the other say which is
equivalent to not hearing.

regards

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Reco]

Hi.

On Sat, 29 Oct 2016 12:34:44 -0400
Ric Moore  wrote:

> On 10/28/2016 05:39 PM, deloptes wrote:
> > Ric Moore wrote:
> >
> >> pavucontrol should have been a depend on pulseaudio since the beginning
> >> as you can't do squat without it. Try to remove firefox and you lose
> >> your entire desktop. Go figure. Ric
> >
> > Thank you Ric.
> >
> > I don't think pavucontrol depends on pulseaudio
> >
> > apt-cache show pulseaudio
> > Package: pulseaudio
> > Suggests: pavumeter, pavucontrol, paman, paprefs
> 
> Right, pavucontrol is a suggest instead of a depend. I think it should 
> be a depend.

So basically you're proposing to force the user to install GTK3 (with
both C and C++ bindinds) just to install pulseaudio.

There are reasons that this distribution is called Debian, not
You-favorite-enterprisey-tangled-dependency-mess, and one of those
reasons is a careful placement of dependencies.

Reco

Re: ulogd2-pcap - tcpdump unknown file format

[Florian Pelgrim]

Problem found! :)

If you wait long enough tail will not include the file header and
tcpdump will just die.

tail -F -n +1 $my_pcap | tcpdump -nr -
And you are happy again.
Don't even think about not including -n... Depening on how many log
entrys you have it will be slw.

Cheers
Flo



signature.asc
Description: OpenPGP digital signature

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[Ric Moore]

On 10/28/2016 05:39 PM, deloptes wrote:

Ric Moore wrote:


pavucontrol should have been a depend on pulseaudio since the beginning
as you can't do squat without it. Try to remove firefox and you lose
your entire desktop. Go figure. Ric


Thank you Ric.

I don't think pavucontrol depends on pulseaudio

apt-cache show pulseaudio
Package: pulseaudio
Suggests: pavumeter, pavucontrol, paman, paprefs


Right, pavucontrol is a suggest instead of a depend. I think it should 
be a depend.



--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: list installed packages present only in stable

[Rick Thomas]

On Oct 23, 2016, at 5:48 PM, kamaraju kusumanchi  
wrote:

> How can I list all the packages installed on my system that are
> currently part of the stable distribution but not present in either
> testing or sid?


try something like this

aptitude -F ‘%p' search '~i' | while read x; do aptitude --disable-columns  
versions '^'"$x"'$'; done

This will give you a list of all installed packages with the repositories they 
are available from.

Here’s a sample

rbthomas@monk:~$ aptitude -F '%p' search '~i' | grep openocd | while read x; do 
aptitude --disable-columns  versions '^'"$x"'$'; done
Package openocd:  
ih 0.3.1-1  100
ph 0.8.0-4 stable 500

On this machine, I have an ancient version (0.3.1-1) of openocd installed that 
is not available in the stable repo.  There is also a version (0.8.0-4) 
available from the stable repo that does not work in my environment, so I have 
the older version “held”.

This is indicated by the fact that there is no repo in the line beginning with 
“ih”.

A small awk or python script processing the output of the above commands should 
give you what you want.

Enjoy!
Rick

Re: WiFi works during install, not after

[Lisi Reisz]

On Saturday 29 October 2016 15:30:51 Carl Fink wrote:
> On 10/29/2016 10:21 AM, Lisi Reisz wrote:
> > On Wednesday 26 October 2016 18:24:04 Carl Fink wrote:
> >> Thanks.
> >>
> >> I actually remember seeing it now that you remind me.
> >>
> >> Define "desktop". I set up Xfce4.
> >
> > But did you do so DURING INSTALLATION?  So the complete question, which
> > you have still not answered in its entirety, was:
> > "Did you install a desktop during the installation?"
> >
> > Desktop is as defined in tasksel during the installation.  (Tasksel uses
> > the actual word "desktop")
> >
> > The "during", which you have continued to ignore, is important and could
> > be the crux of your problem.
>
> Quibble: not "ignore". Fail to understand the question. Functionally the
> same, intentionality different.
>
> Yes, during installation.

Right, so that is not the problem.  I'm afraid I stand by my ignore - you 
clearly do understand "during", so you were ignoring it!! ;-)

Did you install the laptop stuff during installation?  If not, try rerunning 
tasksel (it is a command that is available and seems not to require root) and 
making sure that you have got the laptop stuff as well as the desktop stuff.  
I don't know what you do about the fact that you have not at this moment got 
running wi-fi, which you did have last time you ran tasksel, but run it 
anyway and see if it helps.

Lisi

Re: Time quandry when dual boot with WinXP Pro

[Lisi Reisz]

On Saturday 29 October 2016 16:29:11 Felix Miata wrote:
> Lisi Reisz composed on 2016-10-29 15:44 (UTC+0100):
> > Windows uses local time for the hardware clock, Linux uses UTC.
>
> By default, yes, but not necessarily:
> https://wiki.archlinux.org/index.php/time#UTC_in_Windows

Ah!  It is a very long time since I used Windows and I had not remembered how 
I used to deal with it.

Lisi

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Reco]

Hi.

On Sat, 29 Oct 2016 15:09:09 +0100
Brian  wrote:

> On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:
> 
> > On Sat, 29 Oct 2016 08:16:18 -0400
> > rhkra...@gmail.com wrote:
> > 
> > > I'll say that the wiki page gave no hint as to which of the three options 
> > > to 
> > > install, or any hint that one might work better than another.
> > 
> > The page is describing 'Producing an automated install of a Debian
> > operating system from a USB stick', to quote it. For such an advanced
> > task it can be safely assumed IMO that the person who's implementing the
> > instruction is familiar with the basic concepts of a 'file system' or
> > 'mounting'.
> 
> The question of providing guidance on which of the three tools to use is
> an interesting one. As far as possible a wiki page like this one should
> stick to facts and technical matters; venturing into the area of opinion
> isn't the way to go, IMO. Do any of these tools have a distinct
> technical advantage for the purpose of installing GRUB is the question
> to ask and answer? If the answer is "no" don't they deserve equal
> exposure?

No advantage that I'm aware of. In fact, the whole paragraph could be
shortened to already existing text:

If you are working within one of the desktop environments it is very
likely the mounting can be done from he file manager which comes with
it. This is because udisks2 will be on the system. A label will
possibly be used for the mount point.



> The tools exist and all can be assumed to work.  The choice of which one
> to use is up to the user. For many users a couple of clicks on a desktop
> will get the stick mounted; others might like the challenge of using a
> new tool. 

My point exactly. Why bother naming all these tools if it all comes down
to "you might use your file manager to do this part for you as well"?


> A few might say - "Hey, interesting, never knew about that;
> I'll give it a go". And then go on to use it in another context.

True, but why stop here? Author(s?) of the page might mention usbmount
and supermount as well.


> > It can be argued (again IMO) that the 3 tools proposed are not the best
> > ones available for the task, or downright redundant due to availability
> > of mount(8), but all three mentioned tools are in fact are links to [2].
> > Broken ones (for me at least), but they are links to manpages for the
> > mentioned tools. Surely a manpage can be viewed as a suitable source of
> > hints you're referring to.
> 
> mount is a root-only tool; the others aren't. Need I say more?

Yes, I believe you do.

The page mentions 'Check the mount point from within the fie manager or
with the command "mount"' (curious typo btw), rightfully assuming that
one does not need to be root to do that.

The bottom of the page mentions at least one operation that needs to be
performed as root, so why exactly mounting USB stick as root is somehow
a bad thing in this context?


> The Debian manpages site is broken and awaiting relocation to a new
> host.

Here I can only assume that this useful service was available at the
time that page was written.


> > >  Of course, 
> > > until this issue came up, no one may have expected one to work better 
> > > than 
> > > another, so then someone reading that page could, quite appropriately, 
> > > try one 
> > > and not the others, and assume that there was no more useful information 
> > > on 
> > > the page.
> > 
> > I agree that the page provides unnecessary choice in this regard, and
> > for the sake of clarity of this topic [3] would be more appropriate.
> 
> Fair enough. But why not udisks2? After all, it will already be on many
> machines.

No reason, really. pmount was mentioned first on the page.


Reco

Re: Time quandry when dual boot with WinXP Pro

[Felix Miata]

Lisi Reisz composed on 2016-10-29 15:44 (UTC+0100):


Windows uses local time for the hardware clock, Linux uses UTC.


By default, yes, but not necessarily:
https://wiki.archlinux.org/index.php/time#UTC_in_Windows
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Time quandry when dual boot with WinXP Pro

[Lisi Reisz]

On Friday 21 October 2016 14:09:38 Richard Owlett wrote:
> I'm creating a preseed.cfg file for installing Debian 8.6 in a
> dual-boot enviroment with some version of MS Windows. There are
> two distinct use cases:
> 1. Two of my machines with WinXP Pro SP3
> 2. A remote (~1000 miles]friend with several machines - some
> with WinXP, others with
>Windows 10 or later.
>
> I have discovered on my WinXP machine that:
> 1. WinXP _displays_ the correct time.
>"Date and Time Properties" - Time Zone set to
>(GMT-06:00)Central Time(US)
>Automatically adjust clock for daylight saving changes
> 2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct
> time
> 3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of
> custom preseed.cfg
>_displays_ a time 5 hours earlier.
>The _display_ is independent of whether
> d-i clock-setup/utc boolean true
> *OR*
> d-i clock-setup/utc boolean false
>is used in the preseed.cfg file.
>
> I'm confused.

Windows uses local time for the hardware clock, Linux uses UTC.  The Live CD 
presumably uses its common sense when looking at the machine on which it is 
required to run.  I don't know.  I am not familiar with the Live CD.

You are presumably at GMT-5, hence displaying 5 hours earlier on the 
assumption that your hardware clock is set to UTC.

Lisi

Re: WiFi works during install, not after

[Brian]

On Sat 29 Oct 2016 at 15:21:57 +0100, Lisi Reisz wrote:

> On Wednesday 26 October 2016 18:24:04 Carl Fink wrote:
> > Thanks.
> >
> > I actually remember seeing it now that you remind me.
> >
> > Define "desktop". I set up Xfce4.
> 
> But did you do so DURING INSTALLATION?  So the complete question, which you 
> have still not answered in its entirety, was:
> "Did you install a desktop during the installation?"
> 
> Desktop is as defined in tasksel during the installation.  (Tasksel uses the 
> actual word "desktop")
> 
> The "during", which you have continued to ignore, is important and could be 
> the crux of your problem.

I got distracted by "Define "desktop"" so based my response on the
assumption Xfce was installed with tasksel. You are correct though, what
was done would be central to having connectivity *after* the install.

As I have said, if Xfce was brought in as part of the install then
/e/n/i is copied over to the new installation. If it was not then
/e/n/i is not copied over and it is left to the user to set up
networking with a chosen application.

-- 
Brian.

Re: WiFi works during install, not after

[Carl Fink]

On 10/29/2016 10:21 AM, Lisi Reisz wrote:

On Wednesday 26 October 2016 18:24:04 Carl Fink wrote:

Thanks.

I actually remember seeing it now that you remind me.

Define "desktop". I set up Xfce4.

But did you do so DURING INSTALLATION?  So the complete question, which you
have still not answered in its entirety, was:
"Did you install a desktop during the installation?"

Desktop is as defined in tasksel during the installation.  (Tasksel uses the
actual word "desktop")

The "during", which you have continued to ignore, is important and could be
the crux of your problem.
Quibble: not "ignore". Fail to understand the question. Functionally the 
same, intentionality different.


Yes, during installation.

--
Carl Fink
c...@finknetwork.com

Re: WiFi works during install, not after

[Lisi Reisz]

On Wednesday 26 October 2016 18:24:04 Carl Fink wrote:
> Thanks.
>
> I actually remember seeing it now that you remind me.
>
> Define "desktop". I set up Xfce4.

But did you do so DURING INSTALLATION?  So the complete question, which you 
have still not answered in its entirety, was:
"Did you install a desktop during the installation?"

Desktop is as defined in tasksel during the installation.  (Tasksel uses the 
actual word "desktop")

The "during", which you have continued to ignore, is important and could be 
the crux of your problem.

Lisi


> On 10/26/2016 01:19 PM, Brian wrote:
> > On Wed 26 Oct 2016 at 12:57:54 -0400, Carl Fink wrote:
> >> Brian (and list):
> >>
> >> I actually went back to the archive
> >> (https://lists.debian.org/debian-user/2016/10/msg00852.html) and I can't
> >> locate your first message containing the mysterious "first question".
> >>
> >> It also isn't in my mailbox.
> >>
> >> Could you perhaps repeat?
> >
> > Certainly. No problem.
> >
> >> Did you install a desktop *during* the installation?
> >
> > (It was in https://lists.debian.org/debian-user/2016/10/msg00819.html)

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Brian]

On Sat 29 Oct 2016 at 15:54:59 +0300, Reco wrote:

> On Sat, 29 Oct 2016 08:16:18 -0400
> rhkra...@gmail.com wrote:
> 
> > I'll say that the wiki page gave no hint as to which of the three options 
> > to 
> > install, or any hint that one might work better than another.
> 
> The page is describing 'Producing an automated install of a Debian
> operating system from a USB stick', to quote it. For such an advanced
> task it can be safely assumed IMO that the person who's implementing the
> instruction is familiar with the basic concepts of a 'file system' or
> 'mounting'.

The question of providing guidance on which of the three tools to use is
an interesting one. As far as possible a wiki page like this one should
stick to facts and technical matters; venturing into the area of opinion
isn't the way to go, IMO. Do any of these tools have a distinct
technical advantage for the purpose of installing GRUB is the question
to ask and answer? If the answer is "no" don't they deserve equal
exposure?

The tools exist and all can be assumed to work.  The choice of which one
to use is up to the user. For many users a couple of clicks on a desktop
will get the stick mounted; others might like the challenge of using a
new tool. A few might say - "Hey, interesting, never knew about that;
I'll give it a go". And then go on to use it in another context.

> It can be argued (again IMO) that the 3 tools proposed are not the best
> ones available for the task, or downright redundant due to availability
> of mount(8), but all three mentioned tools are in fact are links to [2].
> Broken ones (for me at least), but they are links to manpages for the
> mentioned tools. Surely a manpage can be viewed as a suitable source of
> hints you're referring to.

mount is a root-only tool; the others aren't. Need I say more?

The Debian manpages site is broken and awaiting relocation to a new
host.

> >  Of course, 
> > until this issue came up, no one may have expected one to work better than 
> > another, so then someone reading that page could, quite appropriately, try 
> > one 
> > and not the others, and assume that there was no more useful information on 
> > the page.
> 
> I agree that the page provides unnecessary choice in this regard, and
> for the sake of clarity of this topic [3] would be more appropriate.

Fair enough. But why not udisks2? After all, it will already be on many
machines.

> > Someone with a more experimental nature might have tried all three, but, 
> > like 
> > I hope I implied, why would anyone expect that to make a difference?
> 
> Different tools. Different programming languages to implement
> them. Different dependencies for said tools. Surely all of them should
> behave exact the same behavior (sarcasm implied).

Sarcasm noted :).

By its very nature a wiki page has prescriptive aspects to it but that
does not need to be extended to everything on it. Where there is more
than one way to do something there can surely be a case for mentioning
all of them. If choice confuses there is no answer to that apart from a
user tossing a coin.

When it comes to making an archive there would be at least one -user
member who would be profoundly put out if xorriso was not one of the
choices for the task. :)

-- 
Brian.

Re: TTYSnooping error

[Thomas Schmitt]

Hi,

Nicolas George wrote:
> Still, this code should be using PAM instead of reinventing the wheel
> and making it octagonal.

Looks like ttysnoop's wheel was invented one year before PAM's wheel.
  https://sources.debian.net/src/ttysnoop/0.12d-6/ttysnoops.c
  https://en.wikipedia.org/wiki/Pluggable_authentication_module

I understand it uses the password only as extra "security" feature,
because it refuses to start if geteuid() is not 0:
  https://sources.debian.net/src/ttysnoop/0.12d-6/ttysnoops.c/#L522


Have a nice day :)

Thomas

Re: dependencies problem to install lightworks on jessie

[Henning Follmann]

On Fri, Oct 28, 2016 at 05:56:22PM -0400, e Lpe wrote:
> Ok, thanks for the lesson.
> I made a mistake. I apologize.
> I din't saw how as changed Debian distribution and community since 2002.
> It's so far...
> Forget this thread, or mail, call it as you want.
> I will found a solution by myself.
> 
> And thanks to people try to help.
> End off.
> 

No need to be too sensitive about this.
However, just install the dependencies (dev packages) your program
requires. The debian package system is stable and proven to not mess up. So
just install away with confidence. 

-H


-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: Having problem with Debian's Installation Guide Preparing Files for USB Memory Stick Booting

[billwill onggo]

@Stephan Beck,
Sorry, English isnt good enough, may be it's hard to get what i really mean
:(


If you really follow the installation guide
> ch04s03.html.en#usb-copy-flexible, you have to create a syslinux.cfg
> yourself, there is no existing syslinux.cfg (content),
>

There was no existing syslinux.cfg. I followed the instruction, I created
the syslinux.cfg. I wrote these lines into syslinux.cfg :
  1: default vmlinuz
  2: append initrd=initrd.gz

I tried to boot the USB, and it complained about having a 'kernel panic - vfs
unable to ... '

I then edit the syslinux.cfg, replaced them with these four lines:
  1: default debi
  2: label debi
  3: kernel vmlinuz
  4: append initrd=initrd.gz
and the USB disk booted normally, no complain, and proceed to the
installation menu.





Doing it the flexible way, the content of the syslinux.cfg to be created
> should be (it's from the stick I used for a real installation, so
> priority=medium is optional) :
>
> default vmlinuz initrd=initrd.gz priority=medium
>
After having debian installed on my machine, I formatted my USB disk, I
haven't tried your suggestion, but it should work.



My purpose writing this is to confirm that those two lines from
https://www.debian.org/releases/stable/amd64/ch04s03.
html.en#usb-copy-flexible didn't work out for me. The installation guide
might need a tiny fix... (If I'm not wrong)

Debian Jessie itself uses syslinux version 6.03. Creating a USB boot disk
using those two lines in syslinux.cfg will not work.

Refer to the official syslinux site http://www.syslinux.org/wiki/i
ndex.php?title=Directives/append

> Take the following simple configuration:
>
>   DEFAULT mykernel
>   APPEND root=/dev/sda2
>
> Note that the APPEND line here is a *global* directive, as it is not part
> of any LABEL entry.
>
> For Syslinux 4.xx and older, the above simple configuration works as (it
> used to be) expected.
> *Since version 5.00,* the result for the above sample configuration is
> that the *root=/dev/sda2* argument is not parsed, which will lead to
> unexpected results, most probably with some kind of failure to boot the OS.
> In other words, the *global* APPEND is ignored by the DEFAULT directive.
>


Regards,
Bill

Re: Permissions for an entire PARTITION

[Jochen Spieker]

Richard Owlett:
> 
> My original question had (apparently incorrectly assume that partitions
> handled user/group/world permissions in the same manner as file systems.

Even if you found a solution to your problem, this sentence does not
make much sense and I still assume you are confused about a few basics.

Hard disks / SSDs are usualy split into one or more partitions. A
partition is nothing more than a slice of a disk with a given size. It
does not have any permissions except for the permissions of the block
device in /dev that represents it (e.g. /dev/sda1).

Filesystems organize storage space into files and directories. They are
often (but not necessarily) created inside partitions. Since there is
usually a 1:1 relation between partitions and filesystems, many people
use both terms interchangeably but that is technically wrong. You cannot
mount a partition, only a filesystem (which, again, may or may not be
inside a partition).

J.
-- 
Every year I wonder what a tinsel-making machine looks like. And what it
does in summer.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: TTYSnooping error

[Nicolas George]

L'octidi 8 brumaire, an CCXXV, Thomas Schmitt a écrit :
> Possibly something changed with the encryption in the result of
> getpwnam() or getspnam().

When things change in the hashing of passwords, it is reflected in the
prefix of the salt, which is given as second argument.

Still, this code should be using PAM instead of reinventing the wheel
and making it octagonal.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: TTYSnooping error

[Thomas Schmitt]

Hi,

Pietro wrote:
> I really do not understand as I am sure I am typing the correct
> password, what's happening ?

I assume it is about the comparison after

  https://sources.debian.net/src/ttysnoop/0.12d-6/ttysnoops.c/#L411

It tries to compare the inquired encrypted password of SNOOPUSER
with the encrypted input text. SNOOPUSER is supposed to be user id 0,
i.e. superuser. (See ../config.h)
Possibly something changed with the encryption in the result of
getpwnam() or getspnam().

So if you replace the five lines "#ifndef ... #endif" by the single line

  if (1)

then you (and everybody else !) should at least get past the password check.


Have a nice day :)

Thomas

chromium error: Error initializing NSS without a persistent database: NSS error code: -8023

[Yuwen Dai]

Dear all,

I'm using Wheezy and chromium.  Chromium has been worked well until today.
When I run

chromium

from the shell,  i saw this message:

[31:31:1029/204029:ERROR:nss_util.cc(211)] Error initializing NSS without a
persistent database: NSS error code: -8023

and chromium cann't open any page.  The version of chromium is:
 chromium --version
Chromium 37.0.2062.120 Built on Debian 7.6, running on Debian 7.11

I also searched internet,  some people suggested

ln -s /usr/lib/x86_64-linux-gnu/nss/ /usr/lib/nss

I tried, it didn't work.   Any suggestion?  Thanks in advance.

Yuwen

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Reco]

Hi.

On Sat, 29 Oct 2016 08:16:18 -0400
rhkra...@gmail.com wrote:

> On Saturday, October 29, 2016 05:17:30 AM Reco wrote:
> > On Fri, 28 Oct 2016 18:34:10 -0500
> > Richard Owlett  wrote:
> 
> > > But it gave no useful info!
> > 
> > I dunno ;). Quoting the page, this:
> > 
> > Installing GRUB on the USB Stick
> > Install pmount, udevil or udisks2 and use one of the following commands
> > to mount the primary partition. The mount point for pmount
> > is /media/ARCHIVE. ...
> > 
> > pmount /dev/disk/by-label/ARCHIVE ARCHIVE
> > 
> > seems like a useful info to me about mounting certain USB stick to a
> > directory with pmount.
> 
> I'm not the OP or anybody that has participated in this thread so far.

[1] tells me otherwise, for the 'participation' part. I take it that
this e-mail I'm replying to is shared among several people, then?


> I'll say that the wiki page gave no hint as to which of the three options to 
> install, or any hint that one might work better than another.

The page is describing 'Producing an automated install of a Debian
operating system from a USB stick', to quote it. For such an advanced
task it can be safely assumed IMO that the person who's implementing the
instruction is familiar with the basic concepts of a 'file system' or
'mounting'.

It can be argued (again IMO) that the 3 tools proposed are not the best
ones available for the task, or downright redundant due to availability
of mount(8), but all three mentioned tools are in fact are links to [2].
Broken ones (for me at least), but they are links to manpages for the
mentioned tools. Surely a manpage can be viewed as a suitable source of
hints you're referring to.


>  Of course, 
> until this issue came up, no one may have expected one to work better than 
> another, so then someone reading that page could, quite appropriately, try 
> one 
> and not the others, and assume that there was no more useful information on 
> the page.

I agree that the page provides unnecessary choice in this regard, and
for the sake of clarity of this topic [3] would be more appropriate.


> Someone with a more experimental nature might have tried all three, but, like 
> I hope I implied, why would anyone expect that to make a difference?

Different tools. Different programming languages to implement
them. Different dependencies for said tools. Surely all of them should
behave exact the same behavior (sarcasm implied).


> I guess maybe I'm doing the same thing some others seem to do--belaboring a 
> point that maybe shouldn't have even come up as issue.
> 
> If someone read the page and didn't find / recognize a key piece of 
> information 
> on that page, maybe the page could use a revision.

I believe you're missing the point here. The page in question is not
supposed to provide information on mounting anything as a *key piece*
in the first place due to very nature of the topic the page describes.

But since such information is in there for some reason, and it's
covering *both* mounting and unmounting in a compact enough form - it
can be used as an example for mounting and unmounting also.


Reco

[1]
https://lists.debian.org/msgid-search/201610260711.18646.rhkra...@gmail.com

[2] http://manpages.debian.org/

[3] https://wiki.debian.org/pmount

Re: Licence de Virtualbox

[base10]

Bonjour,

Trouvé dans le changelog sur paquet source virtualbox :
(http://metadata.ftp-master.debian.org/changelogs/contrib/v/virtualbox/virtualbox_5.1.8-dfsg-6_copyright)

This package is not part of the Debian operating system.
It is in the "contrib" area of the Debian archive because it requires a
non-free compiler (Open Watcom) to build the BIOS.
Upstream provides pre-built BIOS images which is used instead.

Cordialement.

> Bonjour,
On Sat, Oct 29, 2016 at 11:57:11AM +, Benoit B wrote:
> 
> J'envisage d'installer virtualBox.
> Sur la page de téléchargement on peut lire : «VirtualBox platform
> packages. The binaries are released under the terms of the GPL version
> 2»
> Cf.
> https://www.virtualbox.org/wiki/Downloads
> 
> Mais il se trouve dans le dépôt contribl de debian.
> https://packages.debian.org/jessie/virtualbox
> 
> De quel paquet non libre dont dépend virtualBox ?
> Est-il indispensable ?
> 
> Merci d'avance.
> 
> –
> Benoit
> 

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[rhkramer]

On Saturday, October 29, 2016 05:17:30 AM Reco wrote:
> On Fri, 28 Oct 2016 18:34:10 -0500
> Richard Owlett  wrote:

> > But it gave no useful info!
> 
> I dunno ;). Quoting the page, this:
> 
> Installing GRUB on the USB Stick
> Install pmount, udevil or udisks2 and use one of the following commands
> to mount the primary partition. The mount point for pmount
> is /media/ARCHIVE. ...
> 
> pmount /dev/disk/by-label/ARCHIVE ARCHIVE
> 
> seems like a useful info to me about mounting certain USB stick to a
> directory with pmount.

I'm not the OP or anybody that has participated in this thread so far.

I don't know whether I want to comment or not.

I'll say that the wiki page gave no hint as to which of the three options to 
install, or any hint that one might work better than another.  Of course, 
until this issue came up, no one may have expected one to work better than 
another, so then someone reading that page could, quite appropriately, try one 
and not the others, and assume that there was no more useful information on 
the page.

Someone with a more experimental nature might have tried all three, but, like 
I hope I implied, why would anyone expect that to make a difference?

I guess maybe I'm doing the same thing some others seem to do--belaboring a 
point that maybe shouldn't have even come up as issue.

If someone read the page and didn't find / recognize a key piece of information 
on that page, maybe the page could use a revision.

If it was because no one previously recognized something (like that pmount, 
udevil or udisks2 might each behave slightly different, and that, therefore, 
one might work when another might not), that would seem like another reason to 
consider a revision of the page.

To argue about the subject just makes the list seem unfriendly, to newbies as 
well as "oldbies". ;-)

Licence de Virtualbox

[Benoit B]

Bonjour,

J'envisage d'installer virtualBox.
Sur la page de téléchargement on peut lire : «VirtualBox platform
packages. The binaries are released under the terms of the GPL version
2»
Cf.
https://www.virtualbox.org/wiki/Downloads

Mais il se trouve dans le dépôt contribl de debian.
https://packages.debian.org/jessie/virtualbox

De quel paquet non libre dont dépend virtualBox ?
Est-il indispensable ?

Merci d'avance.

–
Benoit

ulogd2-pcap - tcpdump unknown file format

[Florian Pelgrim]

Hi,

I'm logging dropped packets with ulogd2 into a pcap file so that tcpdump
should be able to read it.
At some point tcpdump is not anymore able to read the file and quits
with "unknown file format".

The file command instead is printing a correct header:
/var/log/ulog/ulogd.pcap: tcpdump capture file (little-endian) - version
2.4 (raw IP, capture length 65536)

Also I still can have the file open and see packets beeing logged but
when I try to open a new tcpdump in another shell I get the error.
When I delete the file and start a new one everything is to be working
again.

Is anyone else also facing this error?
Ideas for starting debugging which is causing the error?

Packet details:
tcpdump: 4.6.2-5+deb8u1
ulogd2: 2.0.4-2+deb8u1
ulogd2-pcap: 2.0.4-2+deb8u1
iptables: 1.4.21-2+b1
Kernel: 3.16.0-4-amd64

Cheers
Flo



signature.asc
Description: OpenPGP digital signature

Re: TTYSnooping error

[Reco]

Hi.

On Sat, 29 Oct 2016 09:45:21 +
Pietro  wrote:

> Hi,
> 
> I have tried to write directly to the author  (c...@miskatonic.inbe.net)
> as reported in the man page but the domain does not exist anymore.

It's an old tool. Such things are to be expected.

> I am lost in a glass of water - as we use to say in Italy - and I really
> do not know where to get some light from as Google is very good ..
> in giving partial answers or to increase the amount of confusion in
> somebody's mind :-)
> 
> The ttysnooping tool which comes with Debian seems to be broken, I can
> successfully log in after having modified the inittabfile but I can't
> snoop anything as all I get from the ttysnooping client is a prompt for
> a password which is swiftly refused - I am assuming the root password is
> what the tool is asking for.

Personally I could never understand why bother implementing such a tool
in the first place, since tty snooping (among the other things) can be
done with relatively simple strace invocation.

Still, according to the package's README.Debian, 'ttysnoop ttyFOO'
requires a root password.

You should probably ensure that your gettys are running with
'-L /usr/sbin/ttysnoops' commandline option.


> I really do not understand as I am sure I am typing the correct
> password, what's happening ?

Install ltrace. Run as root (crucial!):

ltrace ttysnoop 

Post the result here. Feel free to edit out any references to a real
passwords, usernames or hashes of above.


> I have tried to download the sources and compile them for Slackware but
> I am still experiencing the same issue, I am a bit confused by the fact
> that I can't find any "main" repository for the project while there are
> plenty of tarball coming from different Linux distros.

According to [1], upstream site was http://ftp.cc.gatech.edu/, which is
now considered unavailable. According to the 'control' file, one should
be able to grab the source via svn, by using [2].


> Is there a "vanilla" version I can download and play with or, as
> alternative, would you be able to tell me the terribly naive mistake I
> am making ?

Not anymore. Upstream is unavailable.


> The first Google's result does not contain anything "down-loadable" and
> what I have been playing with gives me the issues I have just described:
> 
> https://packages.debian.org/sid/admin/ttysnoop

That's the Debian package's page.


> Is this the "official" website for the project ?
> 
> https://sourceforge.net/projects/ttysnoop/

SourceForge is a warez dump. Don't trust anything downloaded from
there.


Reco

[1]
http://http.debian.net/debian/pool/main/t/ttysnoop/ttysnoop_0.12d-6.debian.tar.gz

[2] svn://anonscm.debian.org/collab-maint/deb-maint/ttysnoop/trunk/

TTYSnooping error

[Pietro]

Hi,

I have tried to write directly to the author  (c...@miskatonic.inbe.net)
as reported in the man page but the domain does not exist anymore.

I am lost in a glass of water - as we use to say in Italy - and I really
do not know where to get some light from as Google is very good ..
in giving partial answers or to increase the amount of confusion in
somebody's mind :-)

The ttysnooping tool which comes with Debian seems to be broken, I can
successfully log in after having modified the inittabfile but I can't
snoop anything as all I get from the ttysnooping client is a prompt for
a password which is swiftly refused - I am assuming the root password is
what the tool is asking for.

I really do not understand as I am sure I am typing the correct
password, what's happening ?

I have tried to download the sources and compile them for Slackware but
I am still experiencing the same issue, I am a bit confused by the fact
that I can't find any "main" repository for the project while there are
plenty of tarball coming from different Linux distros.

Is there a "vanilla" version I can download and play with or, as
alternative, would you be able to tell me the terribly naive mistake I
am making ?

The first Google's result does not contain anything "down-loadable" and
what I have been playing with gives me the issues I have just described:

https://packages.debian.org/sid/admin/ttysnoop

Is this the "official" website for the project ?

https://sourceforge.net/projects/ttysnoop/

Having the latest source would help me as I could start to debug the
code without being in doubt of fixing an already fixed bug,

Thanks a lot.

Pietro.

Re: dependencies problem to install lightworks on jessie

[Lisi Reisz]

On Friday 28 October 2016 22:56:22 e Lpe wrote:
> Ok, thanks for the lesson.
> I made a mistake. I apologize.
> I din't saw how as changed Debian distribution and community since 2002.
> It's so far...
> Forget this thread, or mail, call it as you want.
> I will found a solution by myself.
>
> And thanks to people try to help.
> End off.

We still don't know what you are trying to do.  Brian told you a solution to 
what seems to be your problem.  Why not try it?  If your problem is what it 
seems to be this will solve it.

Lisi
>
> 2016-10-28 14:31 GMT-04:00 Greg Wooledge :
> > On Fri, Oct 28, 2016 at 07:19:47PM +0100, Brian wrote:
> > > 4. There is a way to get your error mesaages in English but I have
> > >forgotten how. Someone will be along in a while to explain how it
> > >is done.
> >
> > If you're working from a command shell, you can do:
> >
> > export LC_ALL=C
> >
> > and then the rest of your commands should all produce output in the
> > "C" locale (traditional US English, ASCII characters only).
> >
> > If you're working with a GUI, then all bets are off.  You might be able
> > to restart the GUI application with the locale variables set differently,
> > but if it's something like a display manager invoked directly from
> > /sbin/init then it could become difficult.  Or, the GUI application may
> > have its own internal language selection.

Re: Vim et xclipboard

[Francois Lafont]

Bonjour,

On 10/27/2016 11:01 PM, base10 wrote:

> Essayez d'utiliser le registre '+' pour cela (sélectionner du texte avec
> 'v' puis le copier avec '"+y'. Ensuite sous X faire [CTRL-V]. Cela
> fonctionne aussi avec coller ('"+p').
> 
> En tout cas cela fonctionne pour moi avec vim lancé dans une terminal et
> je n'ai pas installé vim.gtk.

Ah, c'est curieux car c'est _précisément_ ce qui ne marche pas chez moi
avec vim.basic mais qui marche parfaitement avec vim.gtk (d'où mes messages
précédents d'ailleurs).

Je viens de refaire le test juste à l'instant sous ma Debian Jessie (pas de
backports etc) et je confirme ce comportement sur ma machine.

Peut-être alors qu'il me manque une config dans mon .vimrc pour que ça marche
aussi avec vim.basic ?


-- 
François Lafont

Re: iptables advice

[Pascal Hambourg]

Le 27/10/2016 à 13:36, Pol Hallen a écrit :


I've 2LAN (192.168.1/24 and 192.168.2/24) with these rules:


Please be more precise. Iptables rules are created on nodes (hosts and 
routers), not networks.



iptables -A FORWARD -s 192.168.1/24 -d 0/0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d 192.168.1/24
-j ACCEPT

and same rules for 192.168.2/24: this allow each lan see other lan.


My advice is to use interface names instead of addresses whenever 
possible. Source addresses can be spoofed.



Can I deny only lan2 (192.168.2/24) to see lan1 (192.168.1/24) but allow
lan1 see lan2?


You're not telling us the whole picture, are you ? There are other 
networks, aren't they ?


An iptables rules is not isolated, it is part of a ruleset. To achieve 
the same purpose, different rules may be required for different rulesets.

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Reco]

Hi.

On Fri, 28 Oct 2016 18:34:10 -0500
Richard Owlett  wrote:

> On 10/28/2016 5:17 PM, Brian wrote:
> > On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote:
> >
> >> Be aware sir that you are the cause of:
> >> multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
> >> 10^^Bels
> >> an "innocent"[snicker] senior citizen is about to have many sleepless
> >> nights
> >> multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !
> >>
> >> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> >>> Did you take a look at the package pmount?
> >>> I use it to mount external disks.
> >>> It requires no changes to /etc/fstab.
> >>
> >> Just in case you have not perceived this quiet discrete message:
> >>I have not come across pmount before
> >
> > Yes you have. It is on the wiki page
> >
> >   https://wiki.debian.org/Installation+Archive+USBStick
> >
> > You read this page about a week or so ago (you told us so) but seemed
> > more concerned about its style rather than its substance.
> >
> 
> *BULL*
> Said page may have included the string "pmount".
> 
> But it gave no useful info!

I dunno ;). Quoting the page, this:

Installing GRUB on the USB Stick
Install pmount, udevil or udisks2 and use one of the following commands
to mount the primary partition. The mount point for pmount
is /media/ARCHIVE. ...

pmount /dev/disk/by-label/ARCHIVE ARCHIVE

seems like a useful info to me about mounting certain USB stick to a
directory with pmount.

Reco

Re: Vim et xclipboard

[base10]

Tu peut essayer de voir le contenus du registre '+' avec la commande
':register' pour vérifier si il y a bien dans le registre '+' le texte
que tu souhaite y placer.

Tu peut aussi utiliser alternativement le registre '*' qui lui contient
le contenus du presse papier X (texte en surbrillance collé avec le
clique du milieu de la souris). Idem son contenu peut être obtenus avec
la commande ':register'.

Cordialement.

> base10 a écrit :
> >Bonjour,
> >
> >Essayez d'utiliser le registre '+' pour cela (sélectionner du texte avec
> >'v' puis le copier avec '"+y'. Ensuite sous X faire [CTRL-V]. Cela
> >fonctionne aussi avec coller ('"+p').
> 
>   Bonjour,
> 
>   En fait, c'est très bizarre. Dans certains cas, cela fonctionne
> parfaitement, dans d'autres, ça coince, et je n'arrive pas à trouver ce qui
> reproduit le dysfonctionnement.
> 
>   Cordialement,
> 
>   JKB
> 

Re: Até quando o Debian terá suporte para plataformas de 32 bits?

[Luiz Carlos]

Samuel, o processador é: Intel Atom D2500 1,86Ghz Dual Core

Em 25 de outubro de 2016 19:42, Samuel Henrique 
escreveu:

> Qual é o processador?
>
> Samuel Henrique 
>

Re: Vim et xclipboard

[BERTRAND Joël]

base10 a écrit :

Bonjour,

Essayez d'utiliser le registre '+' pour cela (sélectionner du texte avec
'v' puis le copier avec '"+y'. Ensuite sous X faire [CTRL-V]. Cela
fonctionne aussi avec coller ('"+p').


Bonjour,

	En fait, c'est très bizarre. Dans certains cas, cela fonctionne 
parfaitement, dans d'autres, ça coince, et je n'arrive pas à trouver ce 
qui reproduit le dysfonctionnement.


Cordialement,

JKB