Bug#699077: ITP: isenkram -- Suggest packages to install when inserting new hardware

[Petter Reinholdtsen]

Package: wnpp
Owner: Petter Reinholdtsen 
Severity: wishlist

* Package name: isenkram
  Version : 0.2
  Upstream Author : Petter Reinholdtsen 
* URL : 
http://anonscm.debian.org/gitweb/?p=collab-maint/isenkram.git
* License : GPL
  Programming Lang: Python, Perl, shell
  Description : Suggest packages to install when inserting new hardware

 Try to figure out what packages are need freshly inserted hardware
 dongle.

See http://people.skolelinux.org/pere/blog/tags/isenkram/ >
and the git source for information of the project.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl622jf09t@diskless.uio.no

Re: screen says "Bad tty" if /dev/console is a symlink

[Guillem Jover]

On Sun, 2013-01-27 at 01:30:54 +0400, Игорь Пашев wrote:
> Did I break anything?
> Too paranoid?

Given the “intention” of the previous code, not enough I'd say. :)

About the question of removing the pathname checks, that's something
the maintainers would have to answer.

> Index: screen/tty.sh
> ===
> --- screen.orig/tty.sh  2013-01-26 07:55:33.092171499 +
> +++ screen/tty.sh   2013-01-26 08:56:34.254462991 +
> @@ -1505,12 +1505,29 @@
>  CheckTtyname (tty)
>  char *tty;
>  {
> +  char real[MAX_PATH];

I guess you meant PATH_MAX here, in any case POSIX does not guarantee
MAX variables to be defined, it would be better to use the POSIX.1-2008
variant of realpath(3) that allocates when passed a NULL (by checking
if it's available at configure time).

>struct stat st;
> -
> -  if (lstat(tty, &st) || !S_ISCHR(st.st_mode) ||
> - (st.st_nlink > 1 && strncmp(tty, "/dev/", 5)))
> -return -1;
> -  return 0;
> +  if (0 == lstat(tty, &st)) {
> +if (S_ISCHR(st.st_mode)) {
> +  if ((1 == st.st_nlink) || (0 == strncmp(tty, "/dev/", 5)))
> +  return 0;
> +} else if (S_ISLNK(st.st_mode)) {
> +  if (0 == stat(tty, &st) && S_ISCHR(st.st_mode)) {
> +if (1 == st.st_nlink) {
> +   return 0;
> +} else if (realpath(tty, real)) {

I don't understand why do you a realpath() here depending on the
number of hard links, but see below.

> +#if defined(__sun__)
> +if (!strncmp(real, "/devices/", 9))
> +  return 0;
> +#else
> +if (!strncmp(real, "/dev/", 5))
> +  return 0;
> +#endif
> +}

The first thing to do should be the realpath(), otherwise you are
exposed to TOCTOU issues, also it will simplify the code as you don't
have any longer different codepaths doing mostly the same (here you
check the path in different ways depending on the codepath).

But if the code is using this path to open(2) it later on, then you
should simply do the realpath() before calling this function so that
that same path can be used for that open() call, which means you
don't need to modify this function at all. Otherwise if this function
is called on something like ttyname(3)'s return value, then changing
this function is the correct thing to do.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130127132556.ga24...@gaara.hadrons.org

Re: screen says "Bad tty" if /dev/console is a symlink

[Игорь Пашев]

> I guess you meant PATH_MAX here, in any case POSIX does not guarantee
> MAX variables to be defined, it would be better to use the POSIX.1-2008
> variant of realpath(3) that allocates when passed a NULL (by checking
> if it's available at configure time).

I thought my libc did not support it, but now I see even
canonicalize_file_name() o_O


> I don't understand why do you a realpath() here depending on the
> number of hard links.

Me too, but original code has "(st.st_nlink > 1 && strncmp(tty, "/dev/", 5))",
so if number of links == 1, then there is no pathname check.
No path check -> No realpath mess.

> Otherwise if this function
> is called on something like ttyname(3)'s return value, then changing
> this function is the correct thing to do.

Yes, CheckTtyname() is used with the value returned by ttyname() :
= screen.cc ===
 978 #define SET_TTYNAME(fatal) do \
 979   { \
 980 if (!(attach_tty = ttyname(0))) \
 981   { \
 982 if (fatal) \
 983   Panic(0, "Must be connected to a terminal."); \
 984 else \
 985   attach_tty = ""; \
 986   } \
 987 else \
 988   { \
 989 if (stat(attach_tty, &st)) \
 990   Panic(errno, "Cannot access '%s'", attach_tty); \
 991 if (CheckTtyname(attach_tty)) \
 992   Panic(0, "Bad tty '%s'", attach_tty); \
 993   } \
 994 if (strlen(attach_tty) >= MAXPATHLEN) \
 995   Panic(0, "TtyName too long - sorry."); \
 996   } while (0)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8yk9PKwO5d=LusLVBEVp1z8=axnDMV4ic=hz_rncte...@mail.gmail.com

Re: screen says "Bad tty" if /dev/console is a symlink

[Игорь Пашев]

So, do you mean it is good to do realpath() and only then stat() etc.?

CheckTtyname (tty)
{
  ;
  ;
}

?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8yg12W4wO0=yqg+qfpra5-yacpxtnqo8f-c2jaems9...@mail.gmail.com

Re: screen says "Bad tty" if /dev/console is a symlink

[Adam Borowski]

On Sun, Jan 27, 2013 at 02:25:56PM +0100, Guillem Jover wrote:
> > +  char real[MAX_PATH];
> 
> I guess you meant PATH_MAX here, in any case POSIX does not guarantee
> MAX variables to be defined, it would be better to use the POSIX.1-2008
> variant of realpath(3) that allocates when passed a NULL (by checking
> if it's available at configure time).

Really, I'd say realpath() should call abort() immediately if called with a
non-NULL argument -- it's better to catch buffer overflows immediately
rather than to allow them to linger.

No modern system implements PATH_MAX.  On Linux, it's hardcoded to a random
value of 4096 for compat reasons, so is pathconf(_PC_PATH_MAX), but I really
wish both went the Hurd way and swat away dumb code before we get a DSA.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


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

Re: screen says "Bad tty" if /dev/console is a symlink

[Roger Leigh]

On Sun, Jan 27, 2013 at 04:26:00PM +0100, Adam Borowski wrote:
> On Sun, Jan 27, 2013 at 02:25:56PM +0100, Guillem Jover wrote:
> > > +  char real[MAX_PATH];
> > 
> > I guess you meant PATH_MAX here, in any case POSIX does not guarantee
> > MAX variables to be defined, it would be better to use the POSIX.1-2008
> > variant of realpath(3) that allocates when passed a NULL (by checking
> > if it's available at configure time).
> 
> Really, I'd say realpath() should call abort() immediately if called with a
> non-NULL argument -- it's better to catch buffer overflows immediately
> rather than to allow them to linger.
> 
> No modern system implements PATH_MAX.  On Linux, it's hardcoded to a random
> value of 4096 for compat reasons, so is pathconf(_PC_PATH_MAX), but I really
> wish both went the Hurd way and swat away dumb code before we get a DSA.

Given the amount of work already done by the Hurd porters, would
it be viable to undef PATH_MAX and do a test build to look at how
much this breaks?  The other advantage is that it reduces duplicate
codepaths in all the places where we have #ifdef PATH_MAX
(where the dynamic allocation is done only for Hurd, rather than
across the board).  This alone would remove a whole bunch of
potential bugs and improve the overall code quality and robustness.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130127162025.gf29...@codelibre.net

No native packages?

[Jakub Wilk]

Dmitrijs Ledkovs wrote on his blog[0]:

Generally if software is useful in Debian Project it can be useful for 
other debian-like and unlike projects. In particular native packages do 
not offer the same patching flexibility as 3.0 (quilt), thus forcing 
downstream distributions to inline modify packages without DEP-3 
headers. This hurts us, when trying to merge useful stuff from 
derivatives back into Debian, as changes are not split into individual 
patches.


I would tend to agree that we have too many native packages, though I 
doubt you'll find (m)any supporters of the idea of banning them 
completely.


It's not only about derivatives, but also in-Debian forking, i.e. NMUs. 
NMUing native packages is quite awkward.


I am guilty myself of maintaining a native package (and another one is 
waiting in NEW). However, I will be happy to switch to a non-native 
format once I figure out a releasing work-flow that is convenient for 
me.



[0] 
http://planet.debian.org/#http://blog.surgut.co.uk/2013/01/thoughts-on-debian-package-policies.html

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130127181644.ga6...@jwilk.net

Re: No native packages?

[Gergely Nagy]

Jakub Wilk  writes:

> Dmitrijs Ledkovs wrote on his blog[0]:
>
>> Generally if software is useful in Debian Project it can be useful
>> for other debian-like and unlike projects. In particular native
>> packages do not offer the same patching flexibility as 3.0 (quilt),
>> thus forcing downstream distributions to inline modify packages
>> without DEP-3 
>> headers. This hurts us, when trying to merge useful stuff from
>> derivatives back into Debian, as changes are not split into
>> individual patches.
>
> I would tend to agree that we have too many native packages, though I
> doubt you'll find (m)any supporters of the idea of banning them
> completely.

There are two native packages I maintain, and I've yet to hear a good
reason for making either of them non-native. Making it harder and much
much more inconvenient for downstream distributions to modify them is a
*goal* in these cases: to make it harder to diverge from one
another.

As for no DEP-3? I do sincerely hope that by 2013, everyone's using a
VCS, and we can pick patches from there.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87libemq8v.fsf@algernon.balabit

Re: No native packages?

[Arno Töll]

Hi,

On 27.01.2013 19:32, Gergely Nagy wrote:
> There are two native packages I maintain, and I've yet to hear a good
> reason for making either of them non-native. 

Not knowing your use cases in particular, it would often be good enough
if we could restrict native packages to use cases, where they actually
were designed for.

We have native packages in Debian where people deliberately use them,
because they are more convenient (i.e. less strict) and easier to use
(no need for orig tarballs). I don't think we should endorse that any
further, so I agree with Jakub in that.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Go (golang) packaging, part 2

[Michael Stapelberg]

Hi,

I have been in contact with a few Go people and we have worked out the
following:

Go libraries (not binaries!) should be present in Debian _only_ for the
purpose of building Debian binary packages. They should not be used
directly for Go development¹.

Go library Debian packages such as golang-codesearch-dev will ship the
full source code (required) in /usr/lib/gocode plus statically compiled
object files (not required, but no downsides) compiled with gc from
the golang-go Debian package.

At least at the moment, binaries must be linked statically since dynamic
linking is not yet a viable solution². I acknowledge that this
introduces some unfortunate implications (as discussed in the previous
thread), but we have no alternative at the moment and I think we can
make it work reasonably well.

I intend to upload the codesearch package soon as an example (and
because it’s useful ;-)).

① 
https://wiki.debian.org/MichaelStapelberg/GoPackaging#Why_should_I_use_.2BIBw-go_get.2BIB0_instead_of_apt-get_to_install_Go_libraries.3F
② http://thread.gmane.org/gmane.comp.lang.go.general/81527/focus=81687
  iant (gccgo maintainer) states that one cannot use the go tool to
  build a shared library.

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6k3qyo2z4@midna.zekjur.net

Re: No native packages?

[Gergely Nagy]

Arno Töll  writes:

> Hi,
>
> On 27.01.2013 19:32, Gergely Nagy wrote:
>> There are two native packages I maintain, and I've yet to hear a good
>> reason for making either of them non-native. 
>
> Not knowing your use cases in particular, it would often be good enough
> if we could restrict native packages to use cases, where they actually
> were designed for.

Completely agreed.

> We have native packages in Debian where people deliberately use them,
> because they are more convenient (i.e. less strict) and easier to use
> (no need for orig tarballs). I don't think we should endorse that any
> further, so I agree with Jakub in that.

Perhaps we should figure out how to make it easier to create orig
tarballs (though, gitpkg does a pretty good job there, imo), and prod
the native (ab)users to see how their workflow can be made easier even
with non-native packaging.

-- 
|8]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehh6mnv1.fsf@algernon.balabit

Re: No native packages?

[Wouter Verhelst]

On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
> Dmitrijs Ledkovs wrote on his blog[0]:
> 
> >Generally if software is useful in Debian Project it can be useful
> >for other debian-like and unlike projects. In particular native
> >packages do not offer the same patching flexibility as 3.0
> >(quilt), thus forcing downstream distributions to inline modify
> >packages without DEP-3 headers. This hurts us, when trying to
> >merge useful stuff from derivatives back into Debian, as changes
> >are not split into individual patches.
> 
> I would tend to agree that we have too many native packages,

There can only be "too many" of anything if it is (or can be) harmful in
some way to have the thing in question.

I've yet to see a convincing argument why using native packages would be
harmful in any way. The argument about "merging patches" doesn't
convince me, at all; mostly because "downloading a source package and
inspecting it" isn't what I would consider an interesting way to
communicate with downstreams. Instead, I'd hope they talk to me, or put
their stuff in a SCM repository somewhere (all my packages are), or some
such.

While I agree that in some cases it might be a bad idea to package
something as a native package, for trivial things (like my package
"fdpowermon"), this isn't a big deal; and the overhead of having to deal
with an upstream tarball and/or upstream build system etc is just not
worth it.

> though I doubt you'll find (m)any supporters of the idea of banning
> them completely.
> 
> It's not only about derivatives, but also in-Debian forking, i.e.
> NMUs. NMUing native packages is quite awkward.

That's a bug then, which we should fix. Banning native packages isn't a
fix, however, it's a copout.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130127214939.gk31...@grep.be

Bug#699138: general: Tor, opera, chrom(ium), others lock up gnome on Acer 722. Can not access other CLI terminals.

[Tim G.]

Package: general
Severity: important

Dear Maintainer,

I have recently installed Debian Wheezy on an Acer AspireOne 722. This hardware
required installing firmware-linux-nonfree to get full gnome3 functionality.

Wheezy locks up frequently on this machine. The lock-up is complete. Neither
keys nor touchpad work. I can not ctrl-alt-F1 to a terminal. I must hold down
the power button to resart the machine.

I can not discern what causes the lock-ups. Manually installed web applications
seem more likely to trigger one. Thus, Iceweasel generally will not cause a
problem. Chrome and Chromium will lock up on startup and during browsing
frequently enough to discourage the use of these programs. Opera has never
launched because Wheezy locks up after the EULA. TorBrowser has never launched
because Wheezy locks up as Vidalia attempts to connect. Wheezy will also
occasionally lock up again upon reboot, prior to the login screen. A second
reboot will usually clear the problem. I have since uninstalled Opera, Tor, and
Chrome, and performance improved for a time thereafter.

I had remained hopeful that an apt-get upgrade would eventually resolve these
issues. After one such upgrade, I found Chromium to work to my satisfaction.
I therefore tested Tor yesterday to see if the issue had been resolved there.
Wheezy locked up again while attmpting to run tor. As usual, I shut down by
holding the power button. I have not been able to boot into the gnome shell
since. It now locks up after the login screen, just when I expect the gnome
panel to appear. In recovery mode, I purged tor and autoremoved other tor
packages. The problem persisted, but I found I was able to boot into gnome
classic, which is what I am now using to file this report. I have since purged
and reinstalled gnome-shell and gnome-desktop-environment. The problem persists.

This is a shame because I was starting to greatly enjoy my Debian Wheezy
installation, in spite of these inconveniences. Keep up the good work! 

~Tim G.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130128010055.3804.33589.report...@scarlet.rose.org

Bug#699138: general: Tor, opera, chrom(ium), others lock up gnome on Acer 722. Can not access other CLI terminals.

[Ben Hutchings]

Control: reassign -1 src:linux 3.2.35-2

On Sun, 2013-01-27 at 20:00 -0500, Tim G. wrote:
> Package: general
> Severity: important
> 
> Dear Maintainer,
> 
> I have recently installed Debian Wheezy on an Acer AspireOne 722. This 
> hardware
> required installing firmware-linux-nonfree to get full gnome3 functionality.

Yes, this is required by AMD GPUs.

> Wheezy locks up frequently on this machine. The lock-up is complete. Neither
> keys nor touchpad work. I can not ctrl-alt-F1 to a terminal. I must hold down
> the power button to resart the machine.
[...]

This is presumably a kernel bug.  I'm going to assume you're using the
current version in testing/unstable, which is 3.2.35-2.

Could you try the test packages referred to from
?  I can't promise they will make any
difference but they might.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#699138: general: Tor, opera, chrom(ium), others lock up gnome on Acer 722. Can not access other CLI terminals.

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:linux 3.2.35-2
Bug #699138 [general] general: Tor, opera, chrom(ium), others lock up gnome on 
Acer 722. Can not access other CLI terminals.
Bug reassigned from package 'general' to 'src:linux'.
Ignoring request to alter found versions of bug #699138 to the same values 
previously set
Ignoring request to alter fixed versions of bug #699138 to the same values 
previously set
Bug #699138 [src:linux] general: Tor, opera, chrom(ium), others lock up gnome 
on Acer 722. Can not access other CLI terminals.
Marked as found in versions linux/3.2.35-2.

-- 
699138: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699138
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b699138.135934619022128.transcr...@bugs.debian.org