[Desktop-packages] [Bug 1871503] [NEW] Samsung M2026 doesn't work (patch available)

2020-04-07 Thread Till W.
Public bug reported:

Splix is a free (libre) and open-source alternative to Samsung's closed-
source ULD driver. Next to being free, Splix also offers better
grayscale rendering than Samsung's ULD driver. Splix mainly provides a
raster-to-QPDL filter (QPDL is Samsung's proprietary printer command
language) and PPD files for respective printers.

In the past, I successfully used Splix to print with a Samsung M2022.
When I had to replace the printer with an almost identical M2026 (same
features, same enclosure, just younger) I noticed that the M2026 does
not work with Splix as supplied by Ubuntu. (Printer accepts print jobs
but does only produce empty pages or does not emit a page at all.)

I recently came across a patch (to Splix) from 2019 that makes the M2026
work by adjusting some details in the generated QPDL stream. The patch
was committed here: https://gitlab.com/ScumCoder/splix (looks like a
fork of the SourceForge repository where Splix was available in the
past). Using the code from the Gitlab repo, I was able to successfully
use the M2026 with Ubuntu 18.04.

Is there any way to get this modification into the Ubuntu splix
(printer-driver-splix) package? I'm willing to help by creating a patch
that can be applied against the package's source if needed/desired.

** Affects: splix (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to splix in Ubuntu.
https://bugs.launchpad.net/bugs/1871503

Title:
  Samsung M2026 doesn't work (patch available)

Status in splix package in Ubuntu:
  New

Bug description:
  Splix is a free (libre) and open-source alternative to Samsung's
  closed-source ULD driver. Next to being free, Splix also offers better
  grayscale rendering than Samsung's ULD driver. Splix mainly provides a
  raster-to-QPDL filter (QPDL is Samsung's proprietary printer command
  language) and PPD files for respective printers.

  In the past, I successfully used Splix to print with a Samsung M2022.
  When I had to replace the printer with an almost identical M2026 (same
  features, same enclosure, just younger) I noticed that the M2026 does
  not work with Splix as supplied by Ubuntu. (Printer accepts print jobs
  but does only produce empty pages or does not emit a page at all.)

  I recently came across a patch (to Splix) from 2019 that makes the
  M2026 work by adjusting some details in the generated QPDL stream. The
  patch was committed here: https://gitlab.com/ScumCoder/splix (looks
  like a fork of the SourceForge repository where Splix was available in
  the past). Using the code from the Gitlab repo, I was able to
  successfully use the M2026 with Ubuntu 18.04.

  Is there any way to get this modification into the Ubuntu splix
  (printer-driver-splix) package? I'm willing to help by creating a
  patch that can be applied against the package's source if
  needed/desired.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/splix/+bug/1871503/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1116999] Re: xfreerdp crashed with SIGSEGV in X509_get_issuer_name()

2014-10-07 Thread Till W.
In case you need a server to reproduce the bug with, try connecting to
uniapps.uni-rostock.de with arbitrary domain name, username and
password.

I am rather sure that this server uses a cert signed by an itermediate
CA (because they do it for other services such as HTTP as well.)  I
tried to verify using openssl's s_client tool:

# openssl s_client -connect uniapps.uni-rostock.de:3389
[…]
Certificate chain
 0 s:/C=DE/ST=Mecklenburg-Vorpommern/L=Rostock/O=Universitaet 
Rostock/OU=ITMZ/CN=rds1.uni-rostock.de
   i:/C=DE/O=Universitaet Rostock/OU=Rechenzentrum/CN=Uni Rostock CA - 
G02/emailAddress=c...@uni-rostock.de
 1 s:/C=DE/O=Universitaet Rostock/OU=Rechenzentrum/CN=Uni Rostock CA - 
G02/emailAddress=c...@uni-rostock.de
   i:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01
 2 s:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01
   i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom 
Root CA 2
[…]

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp in Ubuntu.
https://bugs.launchpad.net/bugs/1116999

Title:
  xfreerdp crashed with SIGSEGV in X509_get_issuer_name()

Status in “freerdp” package in Ubuntu:
  Confirmed

Bug description:
  If I try to connect to my workplace's RDP server (64-bit Server 2008 R2), 
xfreerdp crashes.
  The same is true of remmina, but I figured xfreerdp should be simpler to 
backtrace.

  Steps to reproduce:
  1. run xfreerdp winrd-ng.nominum.com
  2. Respond to password prompt with enter -- it doesn't matter.
  3. Crash.

  ProblemType: Crash
  DistroRelease: Ubuntu 12.10
  Package: freerdp-x11 1.0.1-1ubuntu7
  ProcVersionSignature: Ubuntu 3.5.0-22.34-generic 3.5.7.2
  Uname: Linux 3.5.0-22-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.6.1-0ubuntu10
  Architecture: amd64
  Date: Tue Feb  5 22:09:01 2013
  ExecutablePath: /usr/bin/xfreerdp
  InstallationDate: Installed on 2013-01-11 (25 days ago)
  InstallationMedia: Ubuntu 12.10 Quantal Quetzal - Release amd64 (20121017.5)
  MarkForUpload: True
  ProcCmdline: xfreerdp winrd-ng
  ProcCwd: /home/dana/Documents
  RetraceOutdatedPackages: outdated debug symbol package for libc-bin: package 
version 2.15-0ubuntu20 dbgsym version 2.15-0ubuntu20.1
  Signal: 11
  SourcePackage: freerdp
  StacktraceTop:
   X509_get_issuer_name (a=0x7f430019) at x509_cmp.c:133
   crypto_cert_issuer () from 
/tmp/tmpRsJ0tM/usr/lib/x86_64-linux-gnu/libfreerdp-core.so.1.0
   tls_verify_certificate () from 
/tmp/tmpRsJ0tM/usr/lib/x86_64-linux-gnu/libfreerdp-core.so.1.0
   credssp_get_public_key () from 
/tmp/tmpRsJ0tM/usr/lib/x86_64-linux-gnu/libfreerdp-core.so.1.0
   credssp_authenticate () from 
/tmp/tmpRsJ0tM/usr/lib/x86_64-linux-gnu/libfreerdp-core.so.1.0
  Title: xfreerdp crashed with SIGSEGV in X509_get_issuer_name()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo wireshark

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp/+bug/1116999/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 952084] Re: Cannot set solid color background when background fading is disabled

2013-04-12 Thread Till W.
I can reproduce this bug with Ubuntu 12.04 and nautilus
1:3.4.2-0ubuntu8. Even worse, the desktop looks black when solid color
is selected, but actually it is not drawn at all. If I move a window
across the screen, it leaves a persistent trail.

The problem might be compiz-related. If I switch from compiz to
metacity, the solid color background is draw correctly.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/952084

Title:
  Cannot set solid color background when background fading is disabled

Status in Nautilus:
  Expired
Status in “nautilus” package in Ubuntu:
  Confirmed

Bug description:
  When I try to set a solid color as desktop background with background
  fading disabled, all I get is a black background, no matter what color
  I choose in the control center/System Settings. The same works fine if
  I either enable background fading or use a  vertical or horizontal
  'color-shading-type'.

  TEST CASE:
  1. Press Super, type 'Appearance', and open the result.
  2. Make sure you have a background image selected.
  3. Disable background fading from the command line:

  gsettings set org.gnome.nautilus.desktop background-fade false

  4. In the 'Appearance' dialog, try to set a solid color other than
  black.

  RESULT:
  * No matter what color is set, the background will always stay black.

  To go back to the working case, run the following from the command
  line:

  gsettings set org.gnome.nautilus.desktop background-fade true

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: nautilus 1:3.3.91-0ubuntu4
  ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
  Uname: Linux 3.2.0-18-generic x86_64
  ApportVersion: 1.94.1-0ubuntu2
  Architecture: amd64
  Date: Sun Mar 11 09:57:16 2012
  GsettingsChanges:
   org.gnome.nautilus.window-state geometry '927x1027+65+24'
   org.gnome.nautilus.window-state sidebar-width 183
  InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Beta amd64 (20110901)
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nautilus/+bug/952084/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1100320] Re: Annotation Font-Color is unreadable in Evince

2013-03-08 Thread Till W.
Hi everyone!

I am using the Ambiance GTK theme and was affected by this bug. I have Ubuntu 
12.04.2 LTS installed on an AMD64 machine.
I just downloaded and installed the following packages (with dpkg -i):

evince_3.4.0-0ubuntu1.6_amd64.deb (md5sum: bb2e9efd4c8a20b29f2c054e43cda8d7)
evince-common_3.4.0-0ubuntu1.6_all.deb (md5sum: 
3cea48dba3415a523b06449daec9c1dd)
libevince3-3_3.4.0-0ubuntu1.6_amd64.deb (md5sum: 
beed3be2fbebadb22e966a9a7e10fe04)

The text in the annotation popup notes is now black on white background
and is therefore perfectly readable.  The issue is fixed for me.

Thank you to everyone involved in fixing this!

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/1100320

Title:
  Annotation Font-Color is unreadable in Evince

Status in Evince document viewer:
  Fix Released
Status in “evince” package in Ubuntu:
  Fix Released
Status in “evince” source package in Precise:
  Fix Committed

Bug description:
  * Impact: 
  notes added to pdfs are hard to read

  * Test Case:

  0. Select one of the Ubuntu themes
  1. Open a PDF with Evince
  2. Try to add an annotation
  3. Write some text within the annotation

  Expected to Happen:

  The annotation font color is black, so that is readable on white
  background.

  What happens instead:

  The color is yellow, so that all written text is unreadable.

  * Regression potential:
  watch for the text's color of pdf notes

To manage notifications about this bug go to:
https://bugs.launchpad.net/evince/+bug/1100320/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 861272] Re: No easy way to configure primary display

2012-09-09 Thread Till W.
*** This bug is a duplicate of bug 800136 ***
https://bugs.launchpad.net/bugs/800136

The solution described in
https://bugzilla.gnome.org/show_bug.cgi?id=636216 -- dragging the small
black top bar -- is absolutely not obvious to me.

I just want to add that you can change the primary display programmatically 
(and driver-independent) using xrandr:
$ xrandr --output VGA1 --primary

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/861272

Title:
  No easy way to configure primary display

Status in GNOME Control Center:
  Confirmed
Status in “gnome-control-center” package in Ubuntu:
  Triaged

Bug description:
  Whenever a new monitor is plugged, the desktop may switch to an inappropriate 
screen. System settings should permit to change the default monitor, but they 
don't.
  The gnome-display-properties tool (or its equivalent) has regressed from its 
Hardy version, which permitted to set the default monitor. While the current 
one, provided by default in the gnome-control-center package, has much less 
features.
  This is a very bug for normal users which shouldn't have to:
   - Install a third party package to do this very basic operation
   - Rely on drivers and tools of their graphic card, which might not provide a 
specific tool to handle multi-screen or other basic features
   - Hack their xorg configuration, as it is proposed in these kind of 
tutorials [http://doc.ubuntu-fr.org/multi-ecran] (i haven't check on 
ubuntu.com, but i'm sure it is exactly the same)

  Note that this bug should be considered as important because Ubuntu
  people often argue that their system is usable by human beings, and
  then because the tested distribution is an up to date 10.4 LTS (so
  still supported).

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/861272/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 924082] Re: NM fails to connect to campus Wi-Fi network; wicd succeeds -- Centrino Ultimate-N 6300 iwlwifi

2012-09-07 Thread Till W.
I am suffering from the same problem. My NIC is an Intel 6205:

03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
Subsystem: Intel Corporation Centrino Advanced-N 6205 AGN
Flags: bus master, fast devsel, latency 0, IRQ 49
Memory at f250 (64-bit, non-prefetchable) [size=8K]
Capabilities: access denied
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

My observations are:

Almost all WiFi networks work flawless using NetworkManager. However,
with some networks I have persistent problems. I get a connection for a
few minutes following boot-up, after that the NetworkManager icon goes
to scanning and the syslog fllls up with direct probe timed out
messages. I experience this problem *only* in my university. They use
exclusively Cisco equipment. I can look up the access point models if
necessary.

I am rather sure that NetworkManager is part of the problem. I
experience the problem even when trying to connect to an unencrypted
network at my university. However, when I stop NetworkManager and
connect manually (iwconfig wlan0 essid FOO; ifconfig wlan0 up; dhclient
wlan0) the bug does not occur even after hours.

I also tried iwconfig wlan0 power off but this does not fix the
direct probe timeout problem.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/924082

Title:
  NM fails to connect to campus Wi-Fi network; wicd succeeds -- Centrino
  Ultimate-N 6300 iwlwifi

Status in “network-manager” package in Ubuntu:
  Confirmed

Bug description:
  The iwlwifi drivers give exceptional performance on all APs I have
  connected to, be they WEP, WPA or open. The only time this system lets
  me down is when connecting to my campus wireless network.
  NetworkManager will only sometimes connect, and even manually
  configuring with iwconfig does not always work.

  The error usually given is either:

  Jan 30 01:07:51 Beast kernel: [ 8777.748471] wlan0: direct probe to 
00:1a:1e:a0:3b:c0 (try 1/3)
  Jan 30 01:07:51 Beast kernel: [ 8777.945384] wlan0: direct probe to 
00:1a:1e:a0:3b:c0 (try 2/3)
  Jan 30 01:07:51 Beast kernel: [ 8778.144952] wlan0: direct probe to 
00:1a:1e:a0:3b:c0 (try 3/3)
  Jan 30 01:07:52 Beast kernel: [ 8778.344474] wlan0: direct probe to 
00:1a:1e:a0:3b:c0 timed out

  or:

  Nov 30 19:01:27 Beast kernel: [ 1924.850725] wlan0: authenticate with 
00:24:6c:60:d0:00 (try 1)
  Nov 30 19:01:27 Beast kernel: [ 1924.852183] wlan0: 00:24:6c:60:d0:00 denied 
authentication (status 17)

  Other people report that this error may be linked to MAC filtering by
  the AP, but this should not be the case: my old computer with a
  Broadcom BCM4312 had no trouble.

  This bug is also different from several bug reports that complain of
  limited speed or packet loss: when I can connect, the connection is
  flawless. But very often I cannot connecct. The connection is
  generally worse in crowded areas, or areas with many access points.

  lspci:
  Network controller [0280]: Intel Corporation Centrino Ultimate-N 6300 
[8086:4238] (rev 3e)

  ifconfig wlan0:
  wlan0 Link encap:Ethernet  HWaddr 24:77:03:26:e8:50
    inet addr:130.64.153.137  Bcast:130.64.153.255  Mask:255.255.255.0
    inet6 addr: fe80::2677:3ff:fe26:e850/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:1288307 errors:0 dropped:0 overruns:0 frame:0
    TX packets:296448 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1016044127 (1.0 GB)  TX bytes:27674773 (27.6 MB)

   iwconfig wlan0:
  wlan0 IEEE 802.11abgn  ESSID:tuftswireless
    Mode:Managed  Frequency:5.785 GHz  Access Point: 00:24:6C:60:D0:10
    Bit Rate=300 Mb/s   Tx-Power=15 dBm
    Retry  long limit:7   RTS thr:off   Fragment thr:off
    Power Management:off
    Link Quality=61/70  Signal level=-49 dBm
    Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
    Tx excessive retries:2749  Invalid misc:7   Missed beacon:0

  lsmod | grep iw:
  iwlwifi   320164  0
  mac80211  506154  1 iwlwifi
  cfg80211  209294  2 iwlwifi,mac80211

  dmesg | grep wlan:

  [   12.059405] wlan0: direct probe to 00:24:6c:60:d0:00 (try 1/3)
  [   12.258109] wlan0: direct probe to 00:24:6c:60:d0:00 (try 2/3)
  [   12.457695] wlan0: direct probe to 00:24:6c:60:d0:00 (try 3/3)
  [   12.657205] wlan0: direct probe to 00:24:6c:60:d0:00 timed out
  [   20.624778] wlan0: direct probe to 00:24:6c:60:d0:00 (try 1/3)
  [   20.822683] wlan0: direct probe to 00:24:6c:60:d0:00 (try 2/3)
  [   21.022217] wlan0: direct probe to 00:24:6c:60:d0:00 (try 3/3)
  [   21.221788] wlan0: direct probe to 00:24:6c:60:d0:00 timed out
  [   29.105117] wlan0: direct probe to 00:24:6c:60:d0:00 (try 1/3)
  [