Bug#1084021: regression in 2.4.2-3+deb12u8: client hangs retrieving printer information

[Marcin Owsiany]

Just in case it's useful in determining the cause for the corruption,
here's a diff over sorted lists:

$ diff -U 20 *_.json
--- direct_.json 2024-10-04 16:52:12.750114924 +0200
+++ via-cups_.json 2024-10-04 16:51:59.521916969 +0200
@@ -1,26 +1,33 @@
-"custom_max_8.5x14in",
+"",
+"",
+"custom_199.9x151.05mm_199.9x151.05mm",
+"custom_max_5x14in",
 "custom_min_3.5x5in",
 "iso_a4_210x297mm",
 "iso_a5_148x210mm",
 "iso_a6_105x148mm",
 "iso_b5_176x250mm",
 "iso_c6_114x162mm",
 "iso_dl_110x220mm",
 "jis_b5_182x257mm",
 "jpn_chou3_120x235mm",
 "jpn_chou4_90x205mm",
 "jpn_hagaki_100x148mm",
-"jpn_oufuku_148x200mm",
-"jpn_photo-2l_127x177.8mm",
 "na_5x7_5x7in",
 "na_executive_7.25x10.5in",
 "na_foolscap_8.5x13in",
 "na_govt-letter_8x10in",
 "na_index-4x6_4x6in",
 "na_index-5x8_5x8in",
 "na_invoice_5.5x8.5in",
 "na_legal_8.5x14in",
 "na_letter_8.5x11in",
 "na_number-10_4.125x9.5in",
+"oe_8-5x-13-fb_8.5x13in",
+"oe_executive-fb_7.25x10.5in",
+"oe_legal-fb_8.5x14in",
 "oe_photo-l_3.5x5in",
-"om_small-photo_100x150mm",
+"oe_statement-fb_5.5x8.5in",
+"om_b-5-fb_175.94x249.94mm",
+"om_envelope-c-6-fb_113.96x161.97mm",
+"om_envelope-dl-fb_109.98x219.96mm",

Bug#1084021: regression in 2.4.2-3+deb12u8: client hangs retrieving printer information

[Marcin Owsiany]

I managed to upgrade the printer firmware using its embedded webserver UI
(from SAYAWLPP1N001.2137A.00 created 2021-09-06, to SAYAWLPP1N002.2423A.00
to 2024-06-03).
Unfortunately this did not help.

However, I got my hands on the ipptool utility, and this is where it really
gets interesting.

I have now made the printer available via two channels:
- directly over WiFi
- via USB and Debian cups (host A), as before

When I invoke the get-printer attributes on the printer directly like this:

ipptool -j http://192.168.2.102:631/ipp/print get-printer-attributes.test >
direct.json

then the "media-supported" key in the output is correct - no empty values.

However when I do it through the cups server on host A like this:

ipptool -j http://192.168.192.1:631/printers/kotlownia2
get-printer-attributes.test > via-cups.json

I get output with empty values, and an error just like the one found
earlier in host B's error_log:

"media-supported": Bad keyword value "" - invalid character (RFC 8011
section 5.1.4).

So it looks like it's cups itself that injects the invalid empty values!
The printer's response is (and probably was) correct!

The exact difference of the critical part is as follows:

--- direct_.json 2024-10-04 16:39:26.402511781 +0200
+++ via-cups_.json 2024-10-04 16:40:06.891135645 +0200
@@ -1,29 +1,36 @@
 "media-supported": [
-"na_executive_7.25x10.5in",
-"na_letter_8.5x11in",
-"na_legal_8.5x14in",
+"na_5x7_5x7in",
+"oe_photo-l_3.5x5in",
+"na_index-4x6_4x6in",
+"na_foolscap_8.5x13in",
 "na_govt-letter_8x10in",
-"na_invoice_5.5x8.5in",
-"iso_a5_148x210mm",
 "iso_a4_210x297mm",
+"iso_a5_148x210mm",
+"iso_a6_105x148mm",
 "iso_b5_176x250mm",
 "jis_b5_182x257mm",
-"jpn_oufuku_148x200mm",
-"jpn_hagaki_100x148mm",
-"iso_a6_105x148mm",
-"na_index-4x6_4x6in",
-"om_small-photo_100x150mm",
-"na_5x7_5x7in",
-"na_index-5x8_5x8in",
+"na_legal_8.5x14in",
 "na_number-10_4.125x9.5in",
-"iso_dl_110x220mm",
 "iso_c6_114x162mm",
+"iso_dl_110x220mm",
+"na_executive_7.25x10.5in",
+"na_index-5x8_5x8in",
+"na_letter_8.5x11in",
 "jpn_chou3_120x235mm",
 "jpn_chou4_90x205mm",
-"oe_photo-l_3.5x5in",
-"jpn_photo-2l_127x177.8mm",
-"na_foolscap_8.5x13in",
+"jpn_hagaki_100x148mm",
+"custom_199.9x151.05mm_199.9x151.05mm",
+"na_invoice_5.5x8.5in",
+"oe_executive-fb_7.25x10.5in",
+"oe_legal-fb_8.5x14in",
+"oe_statement-fb_5.5x8.5in",
+"om_b-5-fb_175.94x249.94mm",
+"",
+"om_envelope-dl-fb_109.98x219.96mm",
+"om_envelope-c-6-fb_113.96x161.97mm",
+"",
+"oe_8-5x-13-fb_8.5x13in",
 "custom_min_3.5x5in",
-"custom_max_8.5x14in"
+"custom_max_5x14in"
 ],
-"media-default": "iso_a4_210x297mm",
+"media-default": "unknown",

Bug#1084021: regression in 2.4.2-3+deb12u8: client hangs retrieving printer information

[Marcin Owsiany]

pt., 4 paź 2024 o 14:05 Thorsten Alteholz  napisał(a):

> Hi Marcin,
>
> On 04.10.24 13:52, Marcin Owsiany wrote:
>
> Indeed, on host B the following appears at the same time the print dialog
> hangs in evince ("piec" is host A):
>
> E [04/Oct/2024:13:29:44 +0200] HP_Smart_Tank_710_720_series_piec: Printer
> returned invalid data: \"media-supported\": Bad keyword value \"\" -
> invalid character (RFC 8011 section 5.1.4).
>
>
> yes, this message belongs to the new validation of attributes that was
> part of the latest patches.
> Unfortunately this printer does not behave correct, so I think this is
> rather a feature than a bug.
>
> FWIW, I did "sudo grep -R media-supported /etc 2>/dev/null" and that came
> back with nothing. So I guess it's a bug in the printer's firmware? Can I
> work this around somehow on the cups side?
>
>
> yes, this is a bug in the printer's firmware.  cups asks the printer about
> some properties and one of the answers contains a non RFC-conform
> character. Other such characters resulted in an RCE, so this check is
> somewhat important. If there is no other firmware available, I am afraid
> you have to build your own cups package.
>

There is newer firmware, although I do not see a way to apply it from
Debian :-(

One thing I do not understand is why this invalid input is being accepted
over USB, but is a fatal error over TCP?


> The culprit is in 0024-CVE-2024-47175-and-further-hardening.patch for
> scheduler/ipp.c
>

Thanks for the pointer! I'll probably be able to hack around it, but I'm
afraid less technically savvy users might not be so lucky. Perhaps there
should be a break-glass option to keep being able to use one's hardware?

Marcin

Bug#1084021: regression in 2.4.2-3+deb12u8: client hangs retrieving printer information

[Marcin Owsiany]

Thanks for the quick response Thorsten!

pt., 4 paź 2024 o 13:15 Thorsten Alteholz  napisał(a):

> cups now makes more checks with the attributes it gets from the printer,
> so it would be great to know which printer you are using.


It's an HP Smart Tank 720.


> Are there any
> messages in the error log on host A or host B?


Indeed, on host B the following appears at the same time the print dialog
hangs in evince ("piec" is host A):

E [04/Oct/2024:13:29:44 +0200] HP_Smart_Tank_710_720_series_piec: Printer
returned invalid data: \"media-supported\": Bad keyword value \"\" -
invalid character (RFC 8011 section 5.1.4).


> Are you still able to
> print on host A?
>

I had never tried before, but yes, "lpr -P ... file.pdf" worked! \o/

Are you able to try a different printer (maybe even a different
> manufacturer) and check whether you have the same problems with it?


Sorry, I only have this one printer.

FWIW, I did "sudo grep -R media-supported /etc 2>/dev/null" and that came
back with nothing. So I guess it's a bug in the printer's firmware? Can I
work this around somehow on the cups side?

Marcin

Bug#1084021: regression in 2.4.2-3+deb12u8: client hangs retrieving printer information

[Marcin Owsiany]

Package: cups
Version: 2.4.2-3+deb12u8
Severity: serious
X-Debbugs-Cc: t...@security.debian.org

My setup:
- headless host A running cups 2.4.2-3+deb12u8, with printer connected
  via USB, makes the printer available to host B
- host B running cups 2.4.2-3+deb12u7, printing from evince. Works like
  a charm.

Then I:
- upgrade cups on host B to 2.4.2-3+deb12u8
- restart evince, press CTRL+P, select the printer by clicking on it
  once in the printing dialog
- this hangs displaying a (localized) message that I think might be
  something like "Retrieving printer information..." in the original.

I tried other combination of versions. It seems 2.4.2-3+deb12u8 on host
B is what breaks things.

I'm more than happy to provide information on the configuration, just
please let me know what to provide, printing remains a black magic to me
:-(

FWIW the printer looks the same in GNOME printer settings dialog on host
B whether it works for evince or not - the printer address is "(null)"
in both cases.

-- System Information:
Debian Release: 12.7
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.4.2-3+deb12u8
ii  cups-common2.4.2-3+deb12u8
ii  cups-core-drivers  2.4.2-3+deb12u8
ii  cups-daemon2.4.2-3+deb12u8
ii  cups-filters   1.28.17-3+deb12u1
ii  cups-ppdc  2.4.2-3+deb12u8
ii  cups-server-common 2.4.2-3+deb12u8
ii  debconf [debconf-2.0]  1.5.82
ii  ghostscript10.0.0~dfsg-11+deb12u5
ii  libavahi-client3   0.8-10
ii  libavahi-common3   0.8-10
ii  libc6  2.36-9+deb12u8
ii  libcups2   2.4.2-3+deb12u8
ii  libgcc-s1  12.2.0-14
ii  libstdc++6 12.2.0-14
ii  libusb-1.0-0   2:1.0.26-1
ii  poppler-utils  22.12.0-2+b1
ii  procps 2:4.0.2-3

Versions of packages cups recommends:
ii  avahi-daemon  0.8-10
ii  colord1.4.6-2.2

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  smbclient  
ii  udev   252.30-1~deb12u2

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd

Bug#1008611: bambam autopkgtest failure with pygame 2.1

[Marcin Owsiany]

Thanks for the report. Since showing text is proven to still work (as seen
in the screenshots) I suspect the app is no longer receiving the
(simulated) keypresses, because otherwise it should show at least the
colorful "m" letters (even if rendering pictures would stop working for
some reason).

To fix this, I need to figure out a way to interactively run the app
against the new version of the library without messing up my (Debian
stable) system... I'll try running it under xvfb in a container, but other
ideas most welcome :-)

Marcin

Bug#1005438: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl"

[Marcin Owsiany]

Dnia Tue, Feb 22, 2022 at 08:57:25AM +0100, Andreas Tille napisał(a):
> I had a look into this issue since a Debian Med package received a
> testing removal warning.  I can confirm the build fails with
> 
>Segmentation fault
> 
> in the build time test suite.

Just out of curiosity I ran the tests during build under GDB (simply
inserting "gdb --args" right before the "{interpreter}" in the
overrite_dh_auto_test rule in debian/rules).

It seems like the segfault is in the freetype library, when loading a font,
rather than in pygame (though I guess the root cause could be pygame passing
garbage to freetype? - I have zero knowledge about the API).

Cc-ing Hugh in case he can provide some hints about what might be going on here.

This does not change the fact that it would be great to move to pygame2 :-)

loading pygame.tests.freetype_test
loading pygame.tests.ftfont_test

Thread 1 "python3.10" received signal SIGSEGV, Segmentation fault.
0x7fde9aeb34e3 in FT_Done_Face (face=0x7fde96aa04d8) at 
./src/base/ftobjs.c:2836
2836./src/base/ftobjs.c: No such file or directory.
(gdb) bt full
#0  0x7fde9aeb34e3 in FT_Done_Face (face=0x7fde96aa04d8) at 
./src/base/ftobjs.c:2836
error = 35
driver = 
memory = 
node = 
#1  0x7fde9af11479 in ftc_face_node_done (ftcnode=0x1fce450, 
ftcmanager=) at ./src/cache/ftcmanag.c:272
node = 0x1fce450
manager = 
#2  0x7fde9af11872 in FTC_MruList_New (list=0x1ec9928, key=0x7fde970bb200, 
anode=anode@entry=0x7ffce3eb1bc0) at ./src/cache/ftcmru.c:281
error = 1
node = 0x1fce450
memory = 0x1e70c40
#3  0x7fde9af12bbf in FTC_Manager_LookupFace (manager=, 
face_id=face_id@entry=0x7fde970bb200, aface=aface@entry=0x7ffce3eb1be0) at 
./src/cache/ftcmanag.c:324
_pfirst = 
_compare = 0x7fde9af102d0 
_first = 
_node = 
error = 0
mrunode = 0x7fde9ca14638
#4  0x7fde982a5228 in _PGFT_GetFont (ft=ft@entry=0x20bc470, 
fontobj=fontobj@entry=0x7fde970bb1f0) at src_c/freetype/ft_wrap.c:321
error = 
font = 0x0
#5  0x7fde982a550c in init (ft=ft@entry=0x20bc470, 
fontobj=fontobj@entry=0x7fde970bb1f0) at src_c/freetype/ft_wrap.c:386
font = 
#6  0x7fde982a58be in _PGFT_TryLoadFont_Filename (ft=ft@entry=0x20bc470, 
fontobj=fontobj@entry=0x7fde970bb1f0, filename=, 
font_index=) at src_c/freetype/ft_wrap.c:442
filename_alloc = 
file_len = 
#7  0x7fde9829d3d0 in _ftfont_init (self=0x7fde970bb1f0, args=, kwds=) at src_c/_freetype.c:823
kwlist = {0x7fde982a7bb3 "file", 0x7fde982a7cca "size", 0x7fde982a75cc 
"font_index", 0x7fde982a777c "resolution", 0x7fde982a75d7 "ucs4", 0x0}
file = 0x7fde96f44d30
original_file = 0x7fde96f2a240
font_index = 0
face_size = {x = 1280, y = 0}
ucs4 = 0
resolution = 0
size = 0
height = 0
width = 0
x_ppem = 0
y_ppem = 0
rval = -1
source = 
ft = 0x20bc470
#8  0x00599823 in  ()
#9  0x00531efb in _PyObject_MakeTpCall ()
#10 0x0052c946 in _PyEval_EvalFrameDefault ()
#11 0x0053105a in _PyObject_FastCallDictTstate ()
#12 0x005446ab in  ()
#13 0x00532228 in  ()
#14 0x00549149 in PyObject_Call ()
#15 0x00528a93 in _PyEval_EvalFrameDefault ()
#16 0x0053b7ff in _PyFunction_Vectorcall ()
#17 0x00526ca7 in _PyEval_EvalFrameDefault ()
#18 0x0053b7ff in _PyFunction_Vectorcall ()
--Type  for more, q to quit, c to continue without paging--c
#19 0x00526ca7 in _PyEval_EvalFrameDefault ()
#20 0x0054884c in  ()
#21 0x00526aba in _PyEval_EvalFrameDefault ()
#22 0x0053b7ff in _PyFunction_Vectorcall ()
#23 0x00526ca7 in _PyEval_EvalFrameDefault ()
#24 0x0053b7ff in _PyFunction_Vectorcall ()
#25 0x0054893a in  ()
#26 0x00528a93 in _PyEval_EvalFrameDefault ()
#27 0x0053105a in _PyObject_FastCallDictTstate ()
#28 0x005459b9 in _PyObject_Call_Prepend ()
#29 0x005c2c33 in  ()
#30 0x00531efb in _PyObject_MakeTpCall ()
#31 0x0052b9ee in _PyEval_EvalFrameDefault ()
#32 0x0053b7ff in _PyFunction_Vectorcall ()
#33 0x0054893a in  ()
#34 0x00528a93 in _PyEval_EvalFrameDefault ()
#35 0x0053105a in _PyObject_FastCallDictTstate ()
#36 0x005459b9 in _PyObject_Call_Prepend ()
#37 0x005c2c33 in  ()
#38 0x00531efb in _PyObject_MakeTpCall ()
#39 0x0052b9ee in _PyEval_EvalFrameDefault ()
#40 0x0053b7ff in _PyFunction_Vectorcall ()
#41 0x0054893a in  ()
#42 0x00528a93 in _PyEval_EvalFrameDefault ()
#43 0x0053105a in _PyObject_FastCallDictTstate ()
#44 0x005459b9 in _PyObject_Call_Prepend ()
#45 0x005c2c33 in  ()
#46 0x00531efb in _PyObject_MakeTpCall ()
#47 0x0052b9ee in _PyEval_EvalFrameDefault ()
#48 

Bug#973474: Info received (Bug#973474: gnome: Unable to log back in in after screen lock)

[Marcin Owsiany]

tag 973474 -unreproducible -moreinfo
thanks

I think now that I have provided the requested information and we know how
to reproduce the bug, and have a rough idea what the issue is, we can
remove these tags.

Marcin

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Hi again,

wt., 2 mar 2021 o 02:31 Simon McVittie  napisał(a):

> On Mon, 01 Mar 2021 at 22:48:47 +0100, Marcin Owsiany wrote:
> > I installed from debian-bullseye-DI-alpha3-amd64-netinst.iso in
> virt-manager VM
> > with 2 VCPUs and 4GB of RAM.
> > Other than selecting Polish locale and installing ssh server and all
> possible
> > display managers and window environments that debian-installer allows I
> don't
> > remember doing anything special.
>
> I hope that's pl_PL.UTF-8 rather than a non-Unicode character set?
>

Yes, the latin2 nightmare is long gone :-)


> Installing all possible desktop environments probably results in each
> desktop environment having a "thundering herd" of session services all
> trying to jump in and do similar things at around the same time, so it
> doesn't entirely surprise me if some of them end up fighting.
> Unfortunately, the same pile of extra processes also obscures what is
> going on in the log.
>

Right. I made yet another attempt to reproduce this, aiming for as short a
journal log as I could.
The result is "just" 2570 lines this time.
https://people.debian.org/~porridge/journal3.txt
It also includes "logger" markers which I made from a single ssh session,
which helps reduce the overall number of sessions.
It might serve better as a minimal repro for filing an upstream bug.

$ egrep --color 'Session [0-9a-f]|porridge\[[0-9]*\]:' journal3.txt
mar 02 22:37:39 debian systemd[1]: Started Session c1 of user Debian-gdm.
mar 02 22:38:10 debian systemd[1]: Started Session 2 of user porridge.
mar 02 22:38:22 debian porridge[5608]: ssh-logged-in
mar 02 22:38:35 debian porridge[5615]: cinnamon-starting-login
mar 02 22:38:36 debian systemd[1]: Started Session 4 of user porridge.
mar 02 22:38:47 debian systemd-logind[465]: Session c1 logged out. Waiting
for processes to exit.
mar 02 22:38:49 debian porridge[7641]: cinnamon-starting-logout
mar 02 22:38:50 debian systemd-logind[465]: Session 4 logged out. Waiting
for processes to exit.
mar 02 22:38:50 debian systemd[1]: Started Session c2 of user Debian-gdm.
mar 02 22:39:02 debian porridge[7905]: gnome-starting-login
mar 02 22:39:04 debian systemd[1]: Started Session 5 of user porridge.
mar 02 22:39:07 debian systemd-logind[465]: Session c2 logged out. Waiting
for processes to exit.
mar 02 22:39:10 debian porridge[9464]: gnome-starting-screenlock
mar 02 22:39:24 debian porridge[9739]: gnome-attempting-unlock
mar 02 22:39:27 debian porridge[10824]: gnome-stuck
mar 02 22:39:29 debian porridge[10831]: ssh-logging-out
mar 02 22:39:30 debian systemd-logind[465]: Session 2 logged out. Waiting
for processes to exit.
mar 02 22:39:36 debian systemd[1]: Started Session 6 of user porridge.

To summarize the above:
- c1 is the gdm session where I log into cinnamon
- 2 is my ssh session for calling logger
- 4 is the cinnamon X session
- c2 is the gdm session where I log into GNOME
- 5 is the GNOME session
- 6 is another ssh login, irrelevant

And now it's pretty clear that indeed gnome-shell for some reason thinks it
belongs to session 4, while it's part of session 5.

$ grep NoSuchSession journal3.txt
mar 02 22:39:05 debian gnome-shell[7965]: JS ERROR: Could not get a proxy
for the current session: Gio.IOErrorEnum:
GDBus.Error:org.freedesktop.login1.NoSuchSession: No session '4' known

In fact, session 4 is reported to be gone for good 4 seconds before I even
press ENTER after the password to log into GNOME:
mar 02 22:38:57 debian systemd-logind[465]: Removed session 4.
mar 02 22:39:02 debian porridge[7905]: gnome-starting-login

Now back to your questions from the previous time:

> To verify, I subsequently (without rebooting the VM) logged into and out
> of
> > Cinnamon session once more, and then logged into the GNOME session again
> > (without running the logger commands this time), and WAS able to
> reproduce the
> > issue.
> >
> > I have a full output of journalctl for that run of the VM, at [8]https://
> > people.debian.org/~porridge/journal.txt.gz
>
> At what time did you log into and out of Cinnamon, and at what time did you
> log into GNOME?
>
> If they are the last ones in the log,


Sorry, I didn't record the times, but yes, they should be the last two
sessions in this order.


> then the timeline is:
>
> 22:22:47 start to log in to Cinnamon on tty4, logind session 13
> 22:22:58 gdm greeter on tty1 exits
> 22:23:02 log out from Cinnamon
> 22:23:03 gdm vt-switches back to tty1 and launches a new greeter
> 22:23:08 logind session 13 ends
> 22:23:16 start to log in to GNOME (session 15)
>
> This is where it gets confusing. systemd --user process 23531 seems to be
> trying to start a GNOME Shell session on Wayland and on X11 simultaneously

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Hello again,

sob., 27 lut 2021 o 22:28 Simon McVittie  napisał(a):

>  (and then after pressing Enter
> for my test user's password, I'm back to my unlocked session, equivalent
> to ). At what point does
> what you see diverge from that?
>

See the files {1,2,3,4}-*.png in https://people.debian.org/~porridge/ which
illustrate what happens step by step when I try to unlock.


> Given that you see messages from Xorg, I would also expect to see more
> messages than just those. Before locking the screen, please run
>
> logger "before locking"
>
> to leave a marker in the system log; and then please look back through
> the system log at least as far as that marker.
>

Today I managed to reproduce the bug by doing the following:
- boot the VM
- log into the "Cinnamon" session
- log out
- log into the "Gnome" session
- run `logger "before lock"` via ssh into the VM
- lock screen
- try to unlock

This is the contents of journal (from `sudo journalctl`) between the logger
line and the message produced when trying to unlock:
http://paste.debian.net/1187416/

If you look at the systemd journal (as root) instead of syslog, you'll
> also see "auth" messages, which could be relevant: for instance, when
> you enter a wrong password, that should be logged as an "auth" message
> from PAM.
>
> Please describe the steps you took to install your test VM, including
> any non-default settings used? For example, I wonder whether this is
> locale-sensitive - I'm using en_GB.UTF-8 but you seem to be using a
> non-English locale.
>

I installed from debian-bullseye-DI-alpha3-amd64-netinst.iso in
virt-manager VM with 2 VCPUs and 4GB of RAM.
Other than selecting Polish locale and installing ssh server and all
possible display managers and window environments that debian-installer
allows I don't remember doing anything special.


> If your test VM does not contain any personal or confidential data,
> and you can can transfer files off it with ssh, a shared filesystem or
> paste.debian.net, it would be useful to see the entire systemd journal
> (starting from boot) for this procedure:
>
> - boot the VM
> - log in as a user
> - lock the screen
> - unlock with a correct password
>
> and compare it with
> .
>

So as mentioned before the above is not enough to reproduce the bug for me
either.
But I rebooted the VM and tried to reproduce again using the steps I
mentioned above, in order to grab a clean log from boot.
I also ran "logger" commands at a few steps to make the log easier to read,
and... this time the problem did not appear.
My gut feeling is that the additional switching to and from an ssh session
to run these commands slowed me down a little, and the changed timing was
enough for some leftover process from the Cinnamon session to disappear
before I locked the screen.
To verify, I subsequently (without rebooting the VM) logged into and out of
Cinnamon session once more, and then logged into the GNOME session again
(without running the logger commands this time), and WAS able to reproduce
the issue.

I have a full output of journalctl for that run of the VM, at
https://people.debian.org/~porridge/journal.txt.gz


> > Is there perhaps some setting I could tweak to convince gnome-shell to
> produce
> > some debug output when I attempt unlocking?
>
> Try these:
>
> systemctl --user edit gnome-shell@x11.service
> systemctl --user edit gnome-shell@wayland.service
> sudo systemctl edit gdm.service
>
> and in each case, add this:
>
> [Service]
> Environment=G_MESSAGES_DEBUG=all
>

I also attempted to increase verbosity level with the commands you
provided, but the first two ones failed for me:
porridge@debian:~$ systemctl --user edit gnome-shell@x11.service
No files found for gnome-shell@x11.service.
Run 'systemctl edit --user --force --full gnome-shell@x11.service' to
create a new unit.
porridge@debian:~$ systemctl --user edit gnome-shell@wayland.service
No files found for gnome-shell@wayland.service.
Run 'systemctl edit --user --force --full gnome-shell@wayland.service' to
create a new unit.

I wasn't sure whether it was OK to `--force`, or whether editing
gdm.service made sense without the other two. Please advise.

Marcin

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Just a quick note because I think I have a lead, but won't be able to go
through all your suggestions today.

First of all, I'm also unable to reproduce the issue if I go straight to
logging into the Gnome session after booting my VM.

However I am able to reproduce it if I first log into and log out of a few
other session types.
I'm still trying to figure out the minimal set which triggers the issue
consistently, but so far I can see the issue if I:
- boot the VM
- log into LXDE session and log out
- log into Cinnamon session and log out
- log into "System X11 default" session which I think is LXQT in this case,
and log out
- log into Gnome session
- lock the screen through the menu in upper right-hand corner
- try to unlock

FWIW, the message which "journalctl -f" shows (in an ssh session running in
parallel) when I enter the unlock password is:

lut 28 21:48:52 debian gdm-password][38277]: gkr-pam: unlocked login keyring

A few replies to some of your points below, I'll keep digging whenever I
have some free time in the coming week.

sob., 27 lut 2021 o 22:28 Simon McVittie  napisał(a):

> On Sat, 27 Feb 2021 at 19:21:46 +0100, Marcin Owsiany wrote:
> > Regarding the messages I see in syslog, see the screenshot I had
> attached to my
> > previous message.
>
> On a freshly-installed, up to date test VM, you should find that the gdm
> login screen has a grey background, but the gnome-shell lock screen has a
> dark blue background (it's a blurred version of your desktop background,
> for which the default in Debian 11 is going to be dark blue).


Right, I'm pretty sure the weird behaviour is in the lock screen, not the
gdm login screen.


> It would
> be useful if you could describe the steps you use to reproduce this bug,
> and at each step that involves a login screen, say whether the background
> is grey or blue.
>
> Here is a sequence of screenshots illustrating my
> attempt to reproduce this, together with my system log:
> <https://people.debian.org/~smcv/973474/> (and then after pressing Enter
> for my test user's password, I'm back to my unlocked session, equivalent
> to <https://people.debian.org/~smcv/973474/5.png>). At what point does
> what you see diverge from that?
>
> I'm surprised you see messages from Xorg: those should only appear when
> you start a completely new session, not when you just lock and unlock
> the screen. This suggests that maybe the session is crashing, and instead
> of the gnome-shell lock screen on tty7, you are going back to the gdm
> login screen on tty1.
>

As far as I can tell it's not crashing. Could they have been triggered by
switching between virtual consoles?
Going forward I'll try to use a parallel SSH login rather than messing
around with CTRL+ALT+Fx to keep things simpler.


> Given that you see messages from Xorg, I would also expect to see more
> messages than just those. Before locking the screen, please run
>
> logger "before locking"
>
> to leave a marker in the system log; and then please look back through
> the system log at least as far as that marker.
>
> If you look at the systemd journal (as root) instead of syslog, you'll
> also see "auth" messages, which could be relevant: for instance, when
> you enter a wrong password, that should be logged as an "auth" message
> from PAM.
>
> Please describe the steps you took to install your test VM, including
> any non-default settings used? For example, I wonder whether this is
> locale-sensitive - I'm using en_GB.UTF-8 but you seem to be using a
> non-English locale.
>
> If your test VM does not contain any personal or confidential data,
> and you can can transfer files off it with ssh, a shared filesystem or
> paste.debian.net, it would be useful to see the entire systemd journal
> (starting from boot) for this procedure:
>
> - boot the VM
> - log in as a user
> - lock the screen
> - unlock with a correct password
>
> and compare it with
> <https://people.debian.org/~smcv/973474/journalctl_-b.log.gz>.
>
> Or if your test VM contains personal/confidential things, please could
> you try to set up a similar VM without those and reproduce the bug there?
>
> > Is there perhaps some setting I could tweak to convince gnome-shell to
> produce
> > some debug output when I attempt unlocking?
>
> Try these:
>
> systemctl --user edit gnome-shell@x11.service
> systemctl --user edit gnome-shell@wayland.service
> sudo systemctl edit gdm.service
>
> and in each case, add this:
>
> [Service]
> Environment=G_MESSAGES_DEBUG=all
>
> Thanks,
> smcv
>

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Thank you for looking into this Simon.

Regarding the messages I see in syslog, see the screenshot I had attached
to my previous message.

Is there perhaps some setting I could tweak to convince gnome-shell to
produce some debug output when I attempt unlocking?

Marcin

Bug#966438: src:bambam: Autopkgtest fail wiht newer imagemagick*

[Marcin Owsiany]

Bastien, the screenshot is there, in the artifact tarball from autopkgtest.

I had some free time today and took a look at this in some detail. The
problem is indeed in the changed output format from "convert", bambam is
working as expected.

I have a fix ready and hope to upload it this weekend or next week.

wt., 28 lip 2020, 16:54 użytkownik Bastien Roucariès <
roucaries.bast...@gmail.com> napisał:

> Package: src:bambam
> Version: 1.0.1+dfsg-1
> Severity: serious
> Justification: block imagemagick
>
> Dear Maintainer,
>
> Upgrading imagemagick fail due to autopkg test failling for your package.
> See
> https://ci.debian.net/data/autopkgtest/testing/amd64/b/bambam/6448023/log.gz
>
> Could you :
> 1. Fix the failure
> 2. Please in case of error take a screenshot convert it to png and print
> the png as base64 (help debugging)
>
> Bastien
>

Bug#966437: bambam: autopkgtest failure with imagemagick 8:6.9.11.24+dfsg-1

[Marcin Owsiany]

Just a quick note before I get a chance to look at this closer, in case
anyone else wants to take a stab at it.
It's one thing that the color output format changed in a way that the test
program does not know how to parse it. That's easy to fix.

It's more worrying that the reported average color stays at
"srgb(98.0209%,98.0209%,98.0209%)"
for 40 attempts. This means that either the screen color isn't in fact
changing (i.e. the game is broken) or that the way the average color is
calculated by imagemagick has changed in a way which makes it unusable :-/

wt., 28 lip 2020 o 16:36 Adrian Bunk  napisał(a):

> Source: bambam
> Version: 1.0.1+dfsg-1
> Severity: serious
> Tags: bullseye sid
>
> https://ci.debian.net/packages/b/bambam/unstable/amd64/
>
> Test success with imagemagick < 8:6.9.11.24+dfsg-1:
> ...
> On attempt 5 the average screen color was too close to white: 233,230,235.
> On attempt 6 the average screen color was too close to white: 225,223,231.
> On attempt 7 the average screen color was too close to white: 223,220,226.
> ...
>
> Test failure with imagemagick 8:6.9.11.24+dfsg-1:
> ...
> On attempt 37 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> On attempt 38 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> On attempt 39 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> Traceback (most recent call last):
>   File "./debian/tests/smoke-meat", line 101, in 
> main()
>   File "./debian/tests/smoke-meat", line 24, in main
> await_startup()
>   File "./debian/tests/smoke-meat", line 45, in await_startup
> raise Exception('Failed to see bambam start after %d attempts.' %
> attempt_count)
> Exception: Failed to see bambam start after 40 attempts.
>
>
> I suspect the output of convert changed that is parsed in
>
> https://sources.debian.org/src/bambam/1.0.1+dfsg-1/debian/tests/smoke-meat/#L83
>

Bug#838903: A note about switching to the new "Command" applet

[Marcin Owsiany]

FTR, I added a little note that might help anyone wanting to switch to the
"Command" applet from command-runner-applet:
https://github.com/porridge/command-runner-applet/blob/master/README#L15-L18

Bug#909352: Was severity serious intended?

[Marcin Owsiany]

śr., 3 paź 2018, 21:49 użytkownik Adrian Bunk  napisał:

> On Wed, Oct 03, 2018 at 09:14:15PM +0200, Marcin Owsiany wrote:
> > Maybe I'm missing something, but what was the reason for filing #909352
> as
> > serious? Looking at #892016 it does not seem like it was the cause of the
> > segfault? Or was it?
>
> No.
>
> > If not, then getting rid of squeak-plugins-scratch sounds more like a
> > wishlist cleanup request to me than a serious bug.
>
> "package is completely useless" tends to be treated as RC.
>

I'm not sure I agree, since having reverse-dependencies seems to prove the
contrary.


> > All the more that
> > removing squeak-plugins-scratch from testing will cause scratch to be
> > removed, which is not a great outcome for those using it.
> >
> > Can you please provide a rationale or downgrade the severity?
>
> Downgrading the severity wouldn't make sense.
>
> If it is intentional that squeak-plugins-scratch provides only plugins
> that are already in squeak-vm, then this bug should be closed with an
> explanation why this is intentional.
>
> If it is not intentional that squeak-plugins-scratch provides only
> plugins that are already in squeak-vm and it is no longer needed,
> then fixing the two reverse dependencies is trivial.
>

Right, but it still requires work, which nobody volunteered to do so far,
so one could argue that a high severity is a disservice for our users in
the short term...

Anyway, thank you for the explanation.


Marcin

Bug#909352: Was severity serious intended?

[Marcin Owsiany]

Maybe I'm missing something, but what was the reason for filing #909352 as
serious? Looking at #892016 it does not seem like it was the cause of the
segfault? Or was it?

If not, then getting rid of squeak-plugins-scratch sounds more like a
wishlist cleanup request to me than a serious bug. All the more that
removing squeak-plugins-scratch from testing will cause scratch to be
removed, which is not a great outcome for those using it.

Can you please provide a rationale or downgrade the severity?

Marcin

Bug#889740: Info received (Bug#889740: thunderbird: Faulty apparmor configuration)

[Marcin Owsiany]

FTR https://qa.debian.org/bls/packages/x/xmotd.html summarizes them nicely.

Bug#889740: thunderbird: Faulty apparmor configuration

[Marcin Owsiany]

The issue is caused by lack of getTimeStampName declaration in xmotd.c. The
implicit declaration assumed instead causes the pointer to buf to be cast
to an int, in turn causing some truncation of bits which are non-zero in
this case of a static buffer placed in a far location in address space
(probably in some special section when hardening is used). utime() detects
this and returns EFAULT.

The build log shows plenty of warnings, some of which might have a similar
effect.

Bug#886907: libgadu: ftbfs due to -Werror and gnutls_compression_get_name deprecated

[Marcin Owsiany]

Apparently TLS compression is no longer available. The fix would be to
remove the call and the corresponding format in the gg_debug_session call
which uses it.

Bug#723964: Fix uploaded

[Marcin Owsiany]

FTR, I've just uploaded a fix (Gregor's patch #2) to 7-day DELAYED.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750843: test/automatic/connect fails on kfreebsd-* "bind: Cannot assign requested address"

[Marcin Owsiany]

Thanks for filing the bug.

2014-06-07 15:24 GMT+02:00 Andreas Metzler :

> libgadu FTBFS on kfreebsd-*, test/automatic/connect fails with "bind:
> Cannot assign requested address".


FTR, I've seen this a while ago, and asked on debian-bsd for advice
regardng binding to 127.0.0.2, but there was no response.
https://lists.debian.org/debian-bsd/2014/05/msg00047.html

Marcin

Bug#743098: passing NULL argv to gtestutils.

[Marcin Owsiany]

2014-04-06 19:19 GMT+02:00 Andreas Henriksson :

> Hello Marcin Owsiany!
>
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743098
> you wrote:
>
> > This seems to be a regression in glib, which used to support passing an
> > empty argv:
>
> Looks to me like it at best used to work by chance.
>
> Could you please explain what you mean by supported


Only that it used to be accepted, and now crashes the program.


> and
> why you think passing an empty argv is a sane thing to do?
>

It's just one way of passing "nothing". Unless the semantics are
documented, this way is as sane as any other :-)

regards,
Marcin

Bug#743098: ekg2: FTBFS: Makefile.am:144: error: 'plugins/autoresponder/autoresponder.la' is not a standard libtool library name

[Marcin Owsiany]

retitle gtestutils crashes with an empty argv
reassign 743098 libglib2.0-dev
thanks

On Sun, Mar 30, 2014 at 06:46:11PM +0200, David Suárez wrote:
> > make[5]: Entering directory `/«BUILDDIR»/ekg2-0.4~pre+20120506.1'
> > PASS: check_potfiles
> > FAIL: check_ekg2

Apparently the binary segfaults during the test:

warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x7fff705fe000
Core was generated by `./ekg2 -F check -n quit'.
Program terminated with signal 11, Segmentation fault.
#0  0x2b0b0df49c3a in g_test_init () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt full
#0  0x2b0b0df49c3a in g_test_init () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#1  0x2b0b0fd1dfae in check_plugin_init (prio=prio@entry=-254) at 
plugins/check/check.c:26
argc = 0
argv = 0x0
__func__ = "check_plugin_init"
#2  0x00424818 in plugin_load (name=0x974950 "check", 
prio=prio@entry=-254, quiet=quiet@entry=1) at ekg/plugins.c:282
env_ekg_plugins_path = 
init = 0x993b70 "\240M\231"
lib = 
libname = 
plugin = 0x995680
pl = 
plugin_init = 0x2b0b0fd1df60 
__func__ = "plugin_load"
#3  0x0040e60b in main (argc=2, argv=0x7fff7040ad28) at ekg/ekg.c:648
auto_connect = 0
no_global_config = 0
no_config = 0
new_status = 0
print_version = 0
tmp = 0x0
new_descr = 0x0
load_theme = 0x0
new_profile = 0x0
frontend = 0x974950 "check"
err = 0x0
rlim = {rlim_cur = 18446744073709551615, rlim_max = 
18446744073709551615}
(gdb) 

So it's the same as https://bugs.launchpad.net/bugs/1251887
Citing that bug:

(gdb) bt full
#0 parse_args (argv_p=0x7fff49a8cc18, argc_p=0x7fff49a8cc14) at 
/build/buildd/glib2.0-2.38.1/./glib/gtestutils.c:815
argc = 0
argv = 0x0
i = 
e = 
#1 g_test_init (argc=argc@entry=0x7fff49a8cc14, argv=argv@entry=0x7fff49a8cc18) 
at /build/buildd/glib2.0-2.38.1/./glib/gtestutils.c:1120
seedstr = "R02S0449cf08e0df592837157c37845fed72"
args = {{gp_offset = 16, fp_offset = 0, overflow_arg_area = 
0x7fff49a8cc10, reg_save_area = 0x7fff49a8cba0}}
vararg1 = 
fatal_mask = 
__PRETTY_FUNCTION__ = "g_test_init"
#2 0x2b0a5b4dcfde in check_plugin_init (prio=prio@entry=-254) at 
plugins/check/check.c:26
argc = 0
argv = 0x0
__func__ = "check_plugin_init"
[...]
Line 815 is:
  test_argv0 = argv[0];

which leads to a null pointer dereference in this case.

This seems to be a regression in glib, which used to support passing an
empty argv:
http://sources.debian.net/src/glib2.0/2.36.4-1/glib/gtestutils.c

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718060: libgadu: FTBFS: autoreconf: automake-1.11 failed with exit status: 63

[Marcin Owsiany]

On Mon, Nov 11, 2013 at 07:33:38PM +0100, Balint Reczey wrote:
> tags 718060 pending confirmed
> thanks
> 
> Hi,
> 
> On 07/27/2013 10:49 PM, David Suárez wrote:
> ...
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> I have sponsored Mateusz's fix and uploaded it to delayed/2.

I believe the recommended practice is to upload the debdiff to the bug
before or when uploading, but I haven't seen it so far. Am I missing
something?

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714312: closing 714312

[Marcin Owsiany]

close 714312 0.3-1
thanks

-- 
Marcin Owsiany   http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

"Every program in development at MIT expands until it can read mail."
  -- Unknown


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685469: ekg2: missing copyright file

[Marcin Owsiany]

On Sun, Feb 03, 2013 at 05:20:24AM +0100, Andreas Beckmann wrote:
> Followup-For: Bug #685469
> Control: tag -1 patch
> 
> Hi,
> 
> I'm attaching my sugggested patch to fix this problem. The fixup should
> only be performed by ekg2.postinst - ekg2-core should have nothing to do
> as everything is fine within this package.

You're right. My patch was confused and incorrect.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685469: ekg2: missing copyright file - after upgrading from squeeze-backports to wheezy

[Marcin Owsiany]

On Wed, Jan 30, 2013 at 10:49:18PM +0100, Julien Cristau wrote:
> On Wed, Jan 30, 2013 at 12:10:46 +0100, Andreas Beckmann wrote:
> 
> > Followup-For: Bug #685469
> > Control: found -1 1:0.3.1-2
> > 
> > Hi,
> > 
> > the missing copyright file persists after upgrading from
> > squeeze+squeeze-backports with ekg2 from backports installed to wheezy.
> > 
> > That probably means the package also does not properly cleanup when
> > upgrading from an older snapshot of testing to the current testing.
> > 
> In that case it's no longer RC...  We support upgrades from a stable
> release to the next, anything else is not critical.

I was also under the impression that backports are unsupported.

Moreover, while technically a violation of policy, this bug is not such
a big deal for users for two reasons:

1) ekg2 is a metapackage that contains just one filesystem entry: the
/usr/share/doc/ekg2 symlink. While that is broken after upgrade to
1:0.3.1-2, it depends on ekg2-core, so a user would be able to see the
ekg2-core directory next to ekg2 and find the copyright file.

2) when you just "aptitude install ekg2" 1:0.3.1-1~bpo60+1 (squeeze)
then ekg2 will disappear during this installation, as its only sign of
existence (the symlink) will get overwritten by the directory from
ekg2-core. Then when you upgrade to wheezy, /usr/share/doc/ekg2 will
disappear as ekg2-core is upgraded, and if you install ekg2 afterwards,
all will be back to normal.

However if you reinstall ekg2 before the upgrade, this bug will not
auto-heal on upgrade, so I would like to get a fix out. I've prepared a
fix for squeeze and I could upload it if I get release-team's blessing.
Interdiff below.

I think that putting a fix into squeeze is preferrable to doing one in
squeeze-backports, because:
1) IIRC backports only accept package versions which are already in
testing, which is frozen.
2) even if I do upload a fix to backports somehow, but a user does not
upgrade to that fixed backports version, but straight to squeeze, then
they will never pick up a fix

please let me know what you think

diff -Nru ekg2-0.3.1/debian/changelog ekg2-0.3.1/debian/changelog
--- ekg2-0.3.1/debian/changelog 2012-08-21 22:01:07.0 +0100
+++ ekg2-0.3.1/debian/changelog 2013-01-30 22:06:12.0 +
@@ -1,3 +1,11 @@
+ekg2 (1:0.3.1-3) unstable; urgency=medium
+
+  * RC-bugfix upload aimed at testing
+  * [64d17bb] Add doc directory bug cleanup steps to postinsts.
+(Closes: #685469)
+
+ -- Marcin Owsiany   Wed, 30 Jan 2013 21:45:34 +
+
 ekg2 (1:0.3.1-2) unstable; urgency=medium
 
   * RC-bugfix upload aimed at testing
diff -Nru ekg2-0.3.1/debian/ekg2-core.postinst 
ekg2-0.3.1/debian/ekg2-core.postinst
--- ekg2-0.3.1/debian/ekg2-core.postinst1970-01-01 01:00:00.0 
+0100
+++ ekg2-0.3.1/debian/ekg2-core.postinst2013-01-30 22:06:12.0 
+
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+# Clean up after #685469.
+DOCDIR=/usr/share/doc/ekg2
+if [ -d $DOCDIR ] && [ ! -L $DOCDIR ] ; then
+   rmdir $DOCDIR
+fi
+#DEBHELPER#
diff -Nru ekg2-0.3.1/debian/ekg2.postinst ekg2-0.3.1/debian/ekg2.postinst
--- ekg2-0.3.1/debian/ekg2.postinst 1970-01-01 01:00:00.0 +0100
+++ ekg2-0.3.1/debian/ekg2.postinst 2013-01-30 22:06:12.0 +
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+# Clean up after #685469.
+DOCDIR=/usr/share/doc/ekg2
+if [ ! -e $DOCDIR ] ; then
+   ln -s ekg2-core $DOCDIR
+fi
+#DEBHELPER#


-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668026: libusb upload to testing-proposed-updates

[Marcin Owsiany]

On Wed, Oct 03, 2012 at 07:02:21PM +0100, Adam D. Barratt wrote:
> On Sat, 2012-09-29 at 15:59 +0200, Julien Cristau wrote:
> > On Sat, Sep 22, 2012 at 15:08:42 +0100, Marcin Owsiany wrote:
> > > I've already NMUed libusb 2:0.1.12-23+nmu1 to sid to fix RC bug
> > > #668026 there. However I've also discovered the bug is present in the
> > > version currently in testing (2:0.1.12-20). I suppose the changes in -21
> > > to -23 are not meant/eligible for inclusion in testing, so I'd like to
> > > upload 2:0.1.12-20+nmu1 (interdiff attached) to
> > > testing-proposed-updates. Please let me know if this looks good.
> > > 
> > please go ahead.
> 
> For the record, this was uploaded; thanks. I've added an approve hint
> but the package won't be able to migrate until we can add a
> corresponding unblock-udeb, which will likely be after d-i beta 3 is
> out.

There also seems to be a problem with building it on a couple of
architectures. I've sent a message to openjade@packages.d.o as this is
the tool that fails. I suspect it's a problem with one of its
dependencies...

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#655804: Patch

[Marcin Owsiany]

X-Debbugs-CC: Jakub Wilk 

Here's a patch that follows the first piece of Jakub's advice.

diff -u update-manager-0.200.5/debian/changelog 
update-manager-0.200.5/debian/changelog
--- update-manager-0.200.5/debian/changelog
+++ update-manager-0.200.5/debian/changelog
@@ -1,3 +1,11 @@
+update-manager (0.200.5-2+nmu1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Avoid manipulating the documentation build directory to not step on
+sphinx's toes (closes: #655804).
+
+ -- Marcin Owsiany   Sat, 22 Sep 2012 15:34:35 +0100
+
 update-manager (0.200.5-2) unstable; urgency=medium
 
   * locale.format_suffix.patch: replace locale.format() calls with
diff -u update-manager-0.200.5/debian/rules update-manager-0.200.5/debian/rules
--- update-manager-0.200.5/debian/rules
+++ update-manager-0.200.5/debian/rules
@@ -14,11 +14,12 @@
-mkdir -p $(CURDIR)/doc/source/_static
$(MAKE) -C $(CURDIR)/doc html
mkdir -p $(CURDIR)/debian/tmp/usr/share/doc/update-manager-doc
-   -rm $(CURDIR)/doc/build/html/_static/jquery.js
-   ln -s /usr/share/javascript/jquery/jquery.js \
-   $(CURDIR)/doc/build/html/_static/jquery.js
cp -r $(CURDIR)/doc/build/html \
$(CURDIR)/debian/tmp/usr/share/doc/update-manager-doc
+# Avoid manipulating the documentation build directory: Bug#655804
+   -rm 
$(CURDIR)/debian/tmp/usr/share/doc/update-manager-doc/html/_static/jquery.js
+   ln -s /usr/share/javascript/jquery/jquery.js \
+   
$(CURDIR)/debian/tmp/usr/share/doc/update-manager-doc/html/_static/jquery.js
 
 # copied from CDBS; I cannot use gnome.mk, for it includes autotools.mk
 # although this package does not use autotools; the build, thus, fails.
only in patch2:
unchanged:
--- update-manager-0.200.5.orig/debian/pycompat
+++ update-manager-0.200.5/debian/pycompat
@@ -0,0 +1 @@
+2

The pycompat thing was added automatically by the build AFAICT.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668026: libusb upload to testing-proposed-updates

[Marcin Owsiany]

Hello,

I've already NMUed libusb 2:0.1.12-23+nmu1 to sid to fix RC bug
#668026 there. However I've also discovered the bug is present in the
version currently in testing (2:0.1.12-20). I suppose the changes in -21
to -23 are not meant/eligible for inclusion in testing, so I'd like to
upload 2:0.1.12-20+nmu1 (interdiff attached) to
testing-proposed-updates. Please let me know if this looks good.

regards,
-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC
diff -Nru libusb-0.1.12/debian/changelog libusb-0.1.12/debian/changelog
--- libusb-0.1.12/debian/changelog  2011-12-31 00:52:03.0 +
+++ libusb-0.1.12/debian/changelog  2012-09-22 15:02:30.0 +0100
@@ -1,3 +1,13 @@
+libusb (2:0.1.12-20+nmu1) testing-proposed-updates; urgency=low
+
+  * Non-maintainer upload.
+  * Fix kfreebsd-* FTBFS: ignore the result of the (BSD-only)
+HAVE_OLD_DEV_USB_USB_H configure check, which started misbehaving in 2012.
+We ignore the system-provided API in favour of an embedded copy of a header
+file anyway (closes: #668026).
+
+ -- Marcin Owsiany   Sat, 22 Sep 2012 15:01:25 +0100
+
 libusb (2:0.1.12-20) unstable; urgency=low
 
   * Add symbols files.
diff -Nru libusb-0.1.12/debian/patches/06_bsd.diff 
libusb-0.1.12/debian/patches/06_bsd.diff
--- libusb-0.1.12/debian/patches/06_bsd.diff2011-12-31 10:43:17.0 
+
+++ libusb-0.1.12/debian/patches/06_bsd.diff2012-09-22 14:22:30.0 
+0100
@@ -1,6 +1,8 @@
 a/bsd.c
-+++ b/bsd.c
-@@ -39,7 +39,7 @@
+Index: libusb-0.1.12/bsd.c
+===
+--- libusb-0.1.12.orig/bsd.c   2012-09-22 14:21:07.0 +0100
 libusb-0.1.12/bsd.c2012-09-22 14:22:24.954862503 +0100
+@@ -39,14 +39,22 @@
  #include 
  #include 
  
@@ -9,8 +11,26 @@
  
  #include "usbi.h"
  #ifdef HAVE_CONFIG_H
 /dev/null
-+++ b/freebsd-usb.h
+ #include "config.h"
+ #endif
+ 
+-#ifdef HAVE_OLD_DEV_USB_USB_H
++/*
++ * Since the Debian version includes "freebsd-usb.h" instead of
++ * , the API provided by the latter file does not matter. The
++ * configure check gives false positives as of 2012, but rather than fixing a
++ * check for something we don't use anyway, just unconditionally skip those
++ * definitions.
++ * #ifdef HAVE_OLD_DEV_USB_USB_H
++ */
++#if 0
+ /*
+  * It appears some of the BSD's (OpenBSD atleast) have switched over to a
+  * new naming convention, so we setup some macro's for backward
+Index: libusb-0.1.12/freebsd-usb.h
+===
+--- /dev/null  1970-01-01 00:00:00.0 +
 libusb-0.1.12/freebsd-usb.h2012-09-22 14:21:07.0 +0100
 @@ -0,0 +1,706 @@
 +/*$NetBSD: usb.h,v 1.69 2002/09/22 23:20:50 augustss Exp $*/
 +/*$FreeBSD: src/sys/dev/usb/usb.h,v 1.47.2.1.2.1 2009/04/15 03:14:26 
kensmith Exp $*/

Bug#668026: Patch

[Marcin Owsiany]

The attached patch fixes the FTBFS.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC
diff -Nru libusb-0.1.12/debian/changelog libusb-0.1.12/debian/changelog
--- libusb-0.1.12/debian/changelog  2012-06-03 17:31:31.0 +0100
+++ libusb-0.1.12/debian/changelog  2012-09-22 13:41:35.0 +0100
@@ -1,3 +1,12 @@
+libusb (2:0.1.12-23+nmu1) unstable; urgency=low
+
+  * Fix kfreebsd-* FTBFS: ignore the result of the (BSD-only)
+HAVE_OLD_DEV_USB_USB_H configure check, which started misbehaving in 2012.
+We ignore the system-provided API in favour of an embedded copy of a header
+file anyway (closes: #668026).
+
+ -- Marcin Owsiany   Sat, 22 Sep 2012 12:36:29 +
+
 libusb (2:0.1.12-23) unstable; urgency=low
 
   * Enable the patches in debian/patches/series. 
diff -Nru libusb-0.1.12/debian/patches/06_bsd.diff 
libusb-0.1.12/debian/patches/06_bsd.diff
--- libusb-0.1.12/debian/patches/06_bsd.diff2011-12-31 10:43:17.0 
+
+++ libusb-0.1.12/debian/patches/06_bsd.diff2012-09-22 13:35:40.0 
+0100
@@ -1,6 +1,8 @@
 a/bsd.c
-+++ b/bsd.c
-@@ -39,7 +39,7 @@
+Index: libusb-0.1.12/bsd.c
+===
+--- libusb-0.1.12.orig/bsd.c   2012-09-22 12:28:40.0 +
 libusb-0.1.12/bsd.c2012-09-22 12:35:17.0 +
+@@ -39,14 +39,22 @@
  #include 
  #include 
  
@@ -9,8 +11,26 @@
  
  #include "usbi.h"
  #ifdef HAVE_CONFIG_H
 /dev/null
-+++ b/freebsd-usb.h
+ #include "config.h"
+ #endif
+ 
+-#ifdef HAVE_OLD_DEV_USB_USB_H
++/*
++ * Since the Debian version includes "freebsd-usb.h" instead of
++ * , the API provided by the latter file does not matter. The
++ * configure check gives false positives as of 2012, but rather than fixing a
++ * check for something we don't use anyway, just unconditionally skip those
++ * definitions.
++ * #ifdef HAVE_OLD_DEV_USB_USB_H
++ */
++#if 0
+ /*
+  * It appears some of the BSD's (OpenBSD atleast) have switched over to a
+  * new naming convention, so we setup some macro's for backward
+Index: libusb-0.1.12/freebsd-usb.h
+===
+--- /dev/null  1970-01-01 00:00:00.0 +
 libusb-0.1.12/freebsd-usb.h2012-09-22 12:28:40.0 +
 @@ -0,0 +1,706 @@
 +/*$NetBSD: usb.h,v 1.69 2002/09/22 23:20:50 augustss Exp $*/
 +/*$FreeBSD: src/sys/dev/usb/usb.h,v 1.47.2.1.2.1 2009/04/15 03:14:26 
kensmith Exp $*/

Bug#668026: A bit more info

[Marcin Owsiany]

It seems that the build failure boils down to:

configure:22252: checking if dev/usb/usb.h uses new naming convention
configure:22277: i486-kfreebsd-gnu-g++ -c -g -O2 -D_FORTIFY_SOURCE=2 
conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:43:46: error: invalid use of incomplete type 'struct 
main()::usb_ctl_request'
conftest.cpp:43:25: error: forward declaration of 'struct 
main()::usb_ctl_request'
configure:22283: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "libusb"
| #define PACKAGE_TARNAME "libusb"
| #define PACKAGE_VERSION "0.1.12"
| #define PACKAGE_STRING "libusb 0.1.12"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "libusb"
| #define VERSION "0.1.12"
| #define LIBUSB_MAJOR_VERSION 0
| #define LIBUSB_MINOR_VERSION 1
| #define LIBUSB_MICRO_VERSION 12
| #define LIBUSB_INTERFACE_AGE 4
| #define LIBUSB_BINARY_AGE 8
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define BSD_API 1
| #define LINUX_API 0
| #define DARWIN_API 0
| #define STDC_HEADERS 1
| #define HAVE_VPRINTF 1
| #define HAVE_LIMITS_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_VALUES_H 1
| #define HAVE_VALUES_H 1
| #define HAVE_MEMMOVE 1
| /* end confdefs.h.  */
| #include 
| int
| main ()
| {
|
|int a = ((struct usb_ctl_request *)0L)->ucr_addr
|
|   ;
|   return 0;
| }
configure:22294: result: no

While the successful 2011 build of libusb 2:0.1.12-20 says:
checking if dev/usb/usb.h uses new naming convention... yes

I've verified that changing
#ifdef HAVE_OLD_DEV_USB_USB_H
to
#if 0
in bsd.c makes the package build OK on kfreebsd.


I think this means that usb_ctl_request used to be declared in dev/usb/usb.h
with a ucr_addr member, but is now removed altogether, which configure.in
(incorrectly) interprets as having "old naming convention".

Perhaps kfreebsd-kernel-headers maintainer(s) can provide some confirmation of
my theory and maybe an explanation on the reasons for removal.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668026: libusb 2:0.1.12-20 does not build any more either

[Marcin Owsiany]

The last version of libusb which built successfully on kfreebsd-* was
2:0.1.12-20, that was on the last day of 2011.

However it does not build any more, I just tried in sid-kfreebsd-i386-dchroot
on fischer - see messages below. This strongly suggests that the FTBFS in
2:0.1.12-21 is not due to a change to libusb, but due to an unrelated change in
some kfreebsd API.

 i486-kfreebsd-gnu-gcc -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -Werror -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
-Wall -MT bsd.lo -MD -MP -MF .deps/bsd.Tpo -c ../bsd.c  -fPIC -DPIC -o 
.libs/bsd.o
../bsd.c: In function 'usb_set_altinterface':
../bsd.c:236:7: error: 'struct usb_alt_interface' has no member named 
'interface_index'
../bsd.c:237:7: error: 'struct usb_alt_interface' has no member named 'alt_no'
../bsd.c: In function 'usb_control_msg':
../bsd.c:457:6: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:458:6: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:459:3: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:459:3: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:459:3: error: left-hand operand of comma expression has no effect 
[-Werror=unused-value]
../bsd.c:460:3: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:460:3: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:460:3: error: left-hand operand of comma expression has no effect 
[-Werror=unused-value]
../bsd.c:461:3: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:461:3: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:461:3: error: left-hand operand of comma expression has no effect 
[-Werror=unused-value]
../bsd.c:463:6: error: 'struct usb_ctl_request' has no member named 'data'
../bsd.c:464:6: error: 'struct usb_ctl_request' has no member named 'flags'
../bsd.c:480:10: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c:480:10: error: 'struct usb_ctl_request' has no member named 'request'
../bsd.c: In function 'usb_os_find_devices':
../bsd.c:541:7: error: 'struct usb_device_info' has no member named 'addr'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: left-hand operand of comma expression has no effect 
[-Werror=unused-value]
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: value computed is not used [-Werror=unused-value]
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: left-hand operand of comma expression has no effect 
[-Werror=unused-value]
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:547:9: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c:552:49: error: 'struct usb_device_info' has no member named 'devnames'
../bsd.c: In function 'usb_control_msg':
../bsd.c:481:1: error: control reaches end of non-void function 
[-Werror=return-type]
cc1: all warnings being treated as errors


-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668354: Downgrading

[Marcin Owsiany]

severity 668354 wishlist
thanks

I had a look at LSB and it agrees with Debian policy in that it also
requires calling a command rather than manipulating symlinks directly.

http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html

  During the installer's post-install processing phase the program
  /usr/lib/lsb/install_initd must be called to activate the init script.
  Activation consists of arranging for the init script to be called in the
  correct order on system run-level changes (including system boot and
  shutdown), based on dependencies supplied in the init script (see
  Comment Conventions for Init Scripts). The install_initd command should
  be thought of as a wrapper which hides the implementation details; how
  any given implementation arranges for the init script to be called at
  the appropriate time is not specified.

As such I don't think this warrants an RC bug. I'm downgrading it to
wishlist. Personally I'd close or mark it wontfix, but I'll leave that
up to the maintainer.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668354: Retitling

[Marcin Owsiany]

retitle 668354 "third-party /etc/rcN.d symlinks are ignored when insserv is in 
use"
thanks

AFAICT the issue is that:
 - muse creates symlinks in /etc/rcN.d directly, rather than using
   update-rc.d, thus insserv never learns about it,
 - when insserv is installed and not explicitly disabled, the symlinks
   are completely ignored

I think this title summarizes the issue much better.

Now, whether this is actually an RC bug is unclear to me. The Debian
policy mandates that init scripts are installed using update-rc.d.
One might say that if muse does not follow Debian policy, it does not
seem fair to claim that sysvinit has a bug...

If sysvinit cared about compatibility with products such as muse, it
could use the following approach:
 - scan all symlinks for runlevel N
 - strip the [SK]XX prefix
 - filter away the names which are in /etc/init.d/.depend.* $TARGETS
 - if any names remain, they must be such legacy scripts - run them
However this procedure would not preserve the correct ordering of
scripts..

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#687109: Patch

[Marcin Owsiany]

tag 687109 + patch
thanks

Attached, please review. If noone speaks up I'll NMU this or next week.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC
Index: debian/control
===
--- debian/control	(wersja 2038)
+++ debian/control	(kopia robocza)
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian XML/SGML Group 
 Uploaders: Ardo van Rangelrooij , Daniel Leidert (dale) 
-Build-Depends: debhelper (>= 5)
+Build-Depends: debhelper (>= 9.20120909)
 Build-Depends-Indep: perl
 Standards-Version: 3.8.3
 Vcs-Browser: http://svn.debian.org/wsvn/debian-xml-sgml/packages/xml-core/
@@ -13,7 +13,7 @@
 Package: xml-core
 Architecture: all
 Depends: ${perl:Depends}, ${misc:Depends}, sgml-base (>= 1.17), sed (>= 4.1.2-8)
-Suggests: debhelper (>= 4.1.75)
+Suggests: debhelper (>= 9.20120909)
 Description: XML infrastructure and XML catalog file support
  This package creates the XML infrastructure directories and provides
  XML catalog file support in compliance with the current Debian XML
Index: debian/changelog
===
--- debian/changelog	(wersja 2038)
+++ debian/changelog	(kopia robocza)
@@ -1,8 +1,10 @@
-xml-core (0.14) UNRELEASED; urgency=low
+xml-core (0.13+nmu1) unstable; urgency=low
 
-  * NOT RELEASED YET
+  * Non-maintainer upload.
+  * Use the "sub" fourth argument to autoscript that is more robust than the
+sed snippet way (closes: #687109)
 
- -- Daniel Leidert (dale)   Sun, 25 Oct 2009 23:59:27 +0100
+ -- Marcin Owsiany   Mon, 10 Sep 2012 21:56:15 +0100
 
 xml-core (0.13) unstable; urgency=low
 
Index: debhelper/dh_installxmlcatalogs
===
--- debhelper/dh_installxmlcatalogs	(wersja 2038)
+++ debhelper/dh_installxmlcatalogs	(kopia robocza)
@@ -108,7 +108,13 @@
 
 ## --
 use Debian::Debhelper::Dh_Lib;
+use Debian::Debhelper::Dh_Version;
 
+$Debian::Debhelper::Dh_Version::version =~ /^(\d+)\.(\d+)/
+	or error("Unexpected debhelper version format");
+# For the "sub" argument to autoscript:
+$1 > 9 or ($1 == 9 and $2 >= '20120909') or error('debhelper 9.20120909 or later required');
+
 ## --
 my $xmlcorever	= "0.12";
 
@@ -124,7 +130,7 @@
 my $cmd = 'update-xmlcatalog';
 $cmd .= ' --add';
 $cmd .= " --type $type";
-$cmd .= " --id \\\"$id\\\"";
+$cmd .= " --id \"$id\"";
 $cmd .= " --package $pkg";
 if ( $local ) {
 	$cmd .= " --local $local";
@@ -141,7 +147,7 @@
 my $cmd = 'update-xmlcatalog';
 $cmd .= ' --del';
 $cmd .= " --type $type";
-$cmd .= " --id \\\"$id\\\"";
+$cmd .= " --id \"$id\"";
 if ( $root ) {
 	$cmd .= " --root";
 } else {
@@ -216,8 +222,8 @@
 		die("error: package command with ID '$id' uses non-existent catalog '$local'\n");
 	}
 	
-	$ADD_PACKAGE .= "\t" . add_xmlcat_cmd($package, $type, $id, $local) . "\\n";
-	$DEL_PACKAGE .= "\t" . del_xmlcat_cmd($package, $type, $id) . "\\n";
+	$ADD_PACKAGE .= "\t" . add_xmlcat_cmd($package, $type, $id, $local) . "\n";
+	$DEL_PACKAGE .= "\t" . del_xmlcat_cmd($package, $type, $id) . "\n";
 
 }
 			} elsif ( $line->[0] eq 'root' ) {
@@ -225,8 +231,8 @@
 
 	my $type = $line->[1];
 	my $id	 = $line->[2];
-	$ADD_ROOT .= "\t" . add_xmlcat_cmd($package, $type, $id) . "\\n";
-	$DEL_ROOT .= "\t" . del_xmlcat_cmd($package, $type, $id, 1) . "\\n";
+	$ADD_ROOT .= "\t" . add_xmlcat_cmd($package, $type, $id) . "\n";
+	$DEL_ROOT .= "\t" . del_xmlcat_cmd($package, $type, $id, 1) . "\n";
 
 }
 			} elsif ( $line->[0] eq 'root-and-package' ) {
@@ -242,10 +248,10 @@
 		die("error: root-and-package command with ID '$id' uses non-existent catalog '$local'\n");
 	}
 
-	$ADD_PACKAGE .= "\t" . add_xmlcat_cmd($package, $type, $id, $local) . "\\n";
-	$DEL_PACKAGE .= "\t" . del_xmlcat_cmd($package, $type, $id) . "\\n";
-	$ADD_ROOT.= "\t" . add_xmlcat_cmd($package, $type, $id) . "\\n";
-	$DEL_ROOT.= "\t" . del_xmlcat_cmd($package, $type, $id, 1) . "\\n";
+	$ADD_PACKAGE .= "\t" . add_xmlcat_cmd($package, $type, $id, $local) . "\n";
+	$

Bug#687109: I'll take a stab at this

[Marcin Owsiany]

I'll take a stab at this this week unless someone beats me to it.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#665296: Putting the sed snippet into a filename

[Marcin Owsiany]

On Sun, Sep 09, 2012 at 01:34:36PM -0400, Joey Hess wrote:
> Marcin Owsiany wrote:
> > +# 4: either text: shell-quoted sed to run on the snippet. Ie, 
> > 's/#PACKAGE#/$PACKAGE/'
> > +#or a sub to run on each line of the snippet. Ie sub { 
> > s/#PACKAGE#/$PACKAGE/ }
> 
> I had not thought about making it operate on each line rather than the
> whole file, but I think I like it.
> 
> > +   } else {
> 
> I use the other brace style in debhelper.
> 
> > +use base 'Test::Class';
> 
> This would add a build dep on libtest-class-perl, it might be easier to
> get this into the freeze if any added tests just used Test::More.

Thanks for the fast review, please see the revised patch attached.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC
>From a63362de35e09e53f72cc3ebcabb40965ee5c43b Mon Sep 17 00:00:00 2001
From: Marcin Owsiany 
Date: Sun, 9 Sep 2012 12:13:20 +0100
Subject: [PATCH] Make it possible to pass perl code to autoscript.

The shell-quoted sed code passed as parameter 4 is fragile (see Bug#665296).
Make it possible to pass a sub that operates on each line via $_ instead.

Also add a basic unit test for Dh_Lib, for now just with tests for autoscript.
---
 Debian/Debhelper/Dh_Lib.pm |   23 ---
 doc/PROGRAMMING|9 ++---
 t/dh-lib   |   31 +++
 3 files changed, 57 insertions(+), 6 deletions(-)
 create mode 100755 t/dh-lib

diff --git a/Debian/Debhelper/Dh_Lib.pm b/Debian/Debhelper/Dh_Lib.pm
index 10ae69f..7b550b0 100644
--- a/Debian/Debhelper/Dh_Lib.pm
+++ b/Debian/Debhelper/Dh_Lib.pm
@@ -504,7 +504,8 @@ sub pkgfilename {
 # 1: package
 # 2: script to add to
 # 3: filename of snippet
-# 4: sed to run on the snippet. Ie, s/#PACKAGE#/$PACKAGE/
+# 4: either text: shell-quoted sed to run on the snippet. Ie, 's/#PACKAGE#/$PACKAGE/'
+#or a sub to run on each line of the snippet. Ie sub { s/#PACKAGE#/$PACKAGE/ }
 sub autoscript {
 	my $package=shift;
 	my $script=shift;
@@ -533,18 +534,34 @@ sub autoscript {
 	   && !compat(5)) {
 		# Add fragments to top so they run in reverse order when removing.
 		complex_doit("echo \"# Automatically added by ".basename($0)."\"> $outfile.new");
-		complex_doit("sed \"$sed\" $infile >> $outfile.new");
+		autoscript_sed($sed, $infile, "$outfile.new");
 		complex_doit("echo '# End automatically added section' >> $outfile.new");
 		complex_doit("cat $outfile >> $outfile.new");
 		complex_doit("mv $outfile.new $outfile");
 	}
 	else {
 		complex_doit("echo \"# Automatically added by ".basename($0)."\">> $outfile");
-		complex_doit("sed \"$sed\" $infile >> $outfile");
+		autoscript_sed($sed, $infile, $outfile);
 		complex_doit("echo '# End automatically added section' >> $outfile");
 	}
 }
 
+sub autoscript_sed {
+	my $sed = shift;
+	my $infile = shift;
+	my $outfile = shift;
+	if (ref($sed) eq 'CODE') {
+		open(IN, $infile) or die "$infile: $!";
+		open(OUT, ">>$outfile") or die "$outfile: $!";
+		while () { $sed->(); print OUT }
+		close(OUT) or die "$outfile: $!";
+		close(IN) or die "$infile: $!";
+	}
+	else {
+		complex_doit("sed \"$sed\" $infile >> $outfile");
+	}
+}
+
 # Removes a whole substvar line.
 sub delsubstvar {
 	my $package=shift;
diff --git a/doc/PROGRAMMING b/doc/PROGRAMMING
index bcf1c13..e1440c9 100644
--- a/doc/PROGRAMMING
+++ b/doc/PROGRAMMING
@@ -191,13 +191,16 @@ isnative($package)
 	is a native debian package.
 	As a side effect, $dh{VERSION} is set to the version number of the
 	package.
-autoscript($package, $scriptname, $snippetname, $sedcommands)
+autoscript($package, $scriptname, $snippetname, $sedcommands || $sub)
 	Pass parameters:
 	 - binary package to be affected
 	 - script to add to
 	 - filename of snippet
-	 - sed commands to run on the snippet. Ie, s/#PACKAGE#/$PACKAGE/
-	   (optional) Note: Passed to the shell inside double quotes.
+	 - (optional) EITHER sed commands to run on the snippet. Ie,
+	   s/#PACKAGE#/$PACKAGE/ Note: Passed to the shell inside double
+   quotes.
+	   OR a perl sub to invoke with $_ set to each line of the snippet in
+   turn.
 	This command automatically adds shell script snippets to a debian
 	maintainer script (like the postinst or prerm).
 	Note that in v6 mode and up, the snippets are added in reverse
diff --git a/t/dh-lib b/t/dh-lib
new file mode 100755
index 000..772b1a1
--- /dev/null
+++ b/t/dh-lib
@@ -0,0 +1,31 @@
+#!/usr/bin/perl
+package Debian::Debhelper::Dh_Lib::Test;
+use strict;
+use warnings;
+

Bug#665296: Putting the sed snippet into a filename

[Marcin Owsiany]

On Sat, Sep 08, 2012 at 03:56:46PM -0400, Joey Hess wrote:
> Marcin Owsiany wrote:
> >  - dh_installxmlcatalogs passing an overly long string to autoscript().
> >  
> >  I think whatever fix is implemented (unless someone knows an answer to my
> >  question above), it will mean a change to dh_installxmlcatalogs. So perhaps
> >  this bug should be cloned against xml-core and it should implement its own
> >  version of autoscript that is safe for long strings (perhaps just copy
> >  autoscript from Dh_Lib and apply the patch below, and remove the extra 
> > quoting
> >  done in dh_installxmlcatalogs).
> 
> Suggestion:
> 
> autoscript($package, $script, $filename, sub { s/// });
> 
> The 4th parameter being a sub can be detected, and the snippet passed
> through it, bypassing sed entirely. Things can migrate over to this new
> interface as needed, without possibly breaking the old interface.

Can you review and include the attachd patch in the squeeze debhelper?

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC
>From e4a629807cae2965517e061c599e1fd170c68e43 Mon Sep 17 00:00:00 2001
From: Marcin Owsiany 
Date: Sun, 9 Sep 2012 12:13:20 +0100
Subject: [PATCH] Make it possible to pass perl code to autoscript.

The shell-quoted sed code passed as parameter 4 is fragile (see Bug#665296).
Make it possible to pass a sub that operates on each line via $_ instead.
---
 Debian/Debhelper/Dh_Lib.pm |   22 +++---
 doc/PROGRAMMING|9 ++---
 t/dh-lib   |   42 ++
 3 files changed, 67 insertions(+), 6 deletions(-)
 create mode 100755 t/dh-lib

diff --git a/Debian/Debhelper/Dh_Lib.pm b/Debian/Debhelper/Dh_Lib.pm
index 10ae69f..5affebb 100644
--- a/Debian/Debhelper/Dh_Lib.pm
+++ b/Debian/Debhelper/Dh_Lib.pm
@@ -504,7 +504,8 @@ sub pkgfilename {
 # 1: package
 # 2: script to add to
 # 3: filename of snippet
-# 4: sed to run on the snippet. Ie, s/#PACKAGE#/$PACKAGE/
+# 4: either text: shell-quoted sed to run on the snippet. Ie, 's/#PACKAGE#/$PACKAGE/'
+#or a sub to run on each line of the snippet. Ie sub { s/#PACKAGE#/$PACKAGE/ }
 sub autoscript {
 	my $package=shift;
 	my $script=shift;
@@ -533,18 +534,33 @@ sub autoscript {
 	   && !compat(5)) {
 		# Add fragments to top so they run in reverse order when removing.
 		complex_doit("echo \"# Automatically added by ".basename($0)."\"> $outfile.new");
-		complex_doit("sed \"$sed\" $infile >> $outfile.new");
+		autoscript_sed($sed, $infile, "$outfile.new");
 		complex_doit("echo '# End automatically added section' >> $outfile.new");
 		complex_doit("cat $outfile >> $outfile.new");
 		complex_doit("mv $outfile.new $outfile");
 	}
 	else {
 		complex_doit("echo \"# Automatically added by ".basename($0)."\">> $outfile");
-		complex_doit("sed \"$sed\" $infile >> $outfile");
+		autoscript_sed($sed, $infile, $outfile);
 		complex_doit("echo '# End automatically added section' >> $outfile");
 	}
 }
 
+sub autoscript_sed {
+	my $sed = shift;
+	my $infile = shift;
+	my $outfile = shift;
+	if (ref($sed) eq 'CODE') {
+		open(IN, $infile) or die "$infile: $!";
+		open(OUT, ">>$outfile") or die "$outfile: $!";
+		while () { $sed->(); print OUT }
+		close(OUT) or die "$outfile: $!";
+		close(IN) or die "$infile: $!";
+	} else {
+		complex_doit("sed \"$sed\" $infile >> $outfile");
+	}
+}
+
 # Removes a whole substvar line.
 sub delsubstvar {
 	my $package=shift;
diff --git a/doc/PROGRAMMING b/doc/PROGRAMMING
index bcf1c13..e1440c9 100644
--- a/doc/PROGRAMMING
+++ b/doc/PROGRAMMING
@@ -191,13 +191,16 @@ isnative($package)
 	is a native debian package.
 	As a side effect, $dh{VERSION} is set to the version number of the
 	package.
-autoscript($package, $scriptname, $snippetname, $sedcommands)
+autoscript($package, $scriptname, $snippetname, $sedcommands || $sub)
 	Pass parameters:
 	 - binary package to be affected
 	 - script to add to
 	 - filename of snippet
-	 - sed commands to run on the snippet. Ie, s/#PACKAGE#/$PACKAGE/
-	   (optional) Note: Passed to the shell inside double quotes.
+	 - (optional) EITHER sed commands to run on the snippet. Ie,
+	   s/#PACKAGE#/$PACKAGE/ Note: Passed to the shell inside double
+   quotes.
+	   OR a perl sub to invoke with $_ set to each line of the snippet in
+   turn.
 	This command automatically adds shell script snippets to a debian
 	maintainer script (like the postinst or prerm).
 	Note that in v6 mode and up, the snippets are added in reverse
diff --git a/t/dh-lib

Bug#665296: Putting the sed snippet into a filename

[Marcin Owsiany]

I'm looking into this as part of BSP in Dublin.


The problem with Niels's fix is that it requires code changes to the program
invoking autoscript, dh_installxmlcatalogs in this case.

I tried Tristan's idea - patch below - and although it works, MY PATCH
INTRODUCES A SUBTLE INCOMPATIBILITY. Here's why:

The fourth parameter to autoscript() is NOT actually a sed one-liner, as
autoscript() documentation claims. It is a string, that is first interpreted by
the shell, and then passed - by the shell - as an argument to "sed". This means
that autoscript() callers need to properly quote some characters, e.g. write:
 \"
rather than
 "
.

When those escaped strings are put into a sed script file (instead via shell)
the sed code is overquoted. While sed "helpfully" just seems to ignore
superfluous backslashes, so I think this would just work for simple use cases,
I'm afraid it might break other valid but more complicated use-cases. So it
does not seem like a good thing to do during the freeze, without a DH_COMPAT
change. And this also means code changes to dh_installxmlcatalogs

Does anyone know a way to strip the quoting in a way compable with the shell,
however without invoking the shell (because in this case it would just barf on
"argument too long")?


So there are a few problems:
 - debhelper misdocumenting the 4th argument to autoscript.

 If it properly mentioned the length of the string is limited due to being
 passed through a shell command-line, then callers might have reconsidered
 before using this functionality to substitute strings of unknown length.
 Ideally the next compatibility version should pass the snippet via a temporary
 file, similar to the patch below.

 - dh_installxmlcatalogs passing an overly long string to autoscript().
 
 I think whatever fix is implemented (unless someone knows an answer to my
 question above), it will mean a change to dh_installxmlcatalogs. So perhaps
 this bug should be cloned against xml-core and it should implement its own
 version of autoscript that is safe for long strings (perhaps just copy
 autoscript from Dh_Lib and apply the patch below, and remove the extra quoting
 done in dh_installxmlcatalogs).


--- /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 2012-08-30 15:16:25.0 
+
+++ Debian/Debhelper/Dh_Lib.pm  2012-09-08 16:42:26.536199119 +
@@ -540,7 +540,12 @@
}
else {
complex_doit("echo \"# Automatically added by 
".basename($0)."\">> $outfile");
-   complex_doit("sed \"$sed\" $infile >> $outfile");
+   use File::Temp qw/tempfile/;
+   my ($fh, $filename) = tempfile();
+   print $fh "$sed";
+   close $fh or die "$filename: $!;
+   warn "filename is $filename";  # for debugging
+   complex_doit("sed -f $filename $infile >> $outfile");
complex_doit("echo '# End automatically added section' >> 
$outfile");
}
 }


-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#629154: Should this bug be downgraded?

[Marcin Owsiany]

I'm looking at this bug as part of the BSP in Dublin, and I have a few
points:


It seems that python-support does support the correct behaviour, and
it's documented how to invoke it. It is the responsibility of the user
of this package (i.e. the maintainer of a package which build-depends on
python-support) to make sure the correct procedure is followed in
postinst.

It would be awesome if it would just DTRT every time out of the box, but
I guess there are valid reasons for it not to do it:
 - I suppose auto-detecting that "update-python-modules -p" should be
   run is non-trivial
 - just running it every time would have major effect on performance,
   and is only really needed in narrow use cases (judging by the lack of
   complaints from other package maintainers)

Thus it seems that the correct severity for this bug would be "wishlist"
rather than "serious".



Having said that, I must say I'm surprised that "python-support" is
going away, as it seems to be used by ~800 packages. Is there a
replacement? What is it?



Now for a minor nitpick: the issue is actually documented in README.gz,
not README.Debian

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685469: ekg2: missing copyright file

[Marcin Owsiany]

tag confirmed
thanks

On Tue, Aug 21, 2012 at 09:30:34AM +0200, Andreas Beckmann wrote:
> [resending, forgot to Cc: the bug]
> 
> On 2012-08-21 08:38, Marcin Owsiany wrote:
> >> # ls -la /usr/share/doc/ekg2
> >> total 0
> >> drwxr-xr-x   2 root root  140 Aug 21 02:42 .
> >> drwxr-xr-x 154 root root 3580 Aug 21 02:42 ..
> >> lrwxrwxrwx   1 root root   26 Nov 14  2011 commands-pl.txt -> 
> >> ../../ekg2/commands-pl.txt
> >> lrwxrwxrwx   1 root root   25 Nov 14  2011 session-en.txt -> 
> >> ../../ekg2/session-en.txt
> >> lrwxrwxrwx   1 root root   25 Nov 14  2011 session-pl.txt -> 
> >> ../../ekg2/session-pl.txt
> >> lrwxrwxrwx   1 root root   22 Nov 14  2011 vars-en.txt -> 
> >> ../../ekg2/vars-en.txt
> >> lrwxrwxrwx   1 root root   22 Nov 14  2011 vars-pl.txt -> 
> >> ../../ekg2/vars-pl.txt
> >> # ls -lad /usr/share/doc/ekg2
> >> drwxr-xr-x 2 root root 140 Aug 21 02:42 /usr/share/doc/ekg2
> > 
> > Interesting. What architecture is this? This looks different on my TV:
> 
> Observed this in a minimal sid chroot on amd64 - its probably important
> to test in a clean minimal chroot that never had anything ekg2 installed.
> 
> # dpkg -S /usr/share/doc/ekg2/*
> ekg2-core: /usr/share/doc/ekg2/commands-pl.txt
> ekg2-core: /usr/share/doc/ekg2/session-en.txt
> ekg2-core: /usr/share/doc/ekg2/session-pl.txt
> ekg2-core: /usr/share/doc/ekg2/vars-en.txt
> ekg2-core: /usr/share/doc/ekg2/vars-pl.txt
> 
> # l -d /usr/share/doc/ekg2*
> drwxr-xr-x 2 root root 140 Aug 21 02:42 /usr/share/doc/ekg2
> drwxr-xr-x 4 root root 340 Aug 21 02:42 /usr/share/doc/ekg2-core
> lrwxrwxrwx 1 root root   9 Nov 14  2011 /usr/share/doc/ekg2-jabber ->
> ekg2-core
> drwxr-xr-x 2 root root 220 Aug 21 02:42 /usr/share/doc/ekg2-ui-ncurses
> 
> # l /usr/share/doc/ekg2-core/
> total 88
> drwxr-xr-x   4 root root   340 Aug 21 02:42 .
> drwxr-xr-x 231 root root  5120 Aug 21 02:53 ..
> -rw-r--r--   1 root root  3967 Mar 19  2011 IDEAS-2.0.gz
> -rw-r--r--   1 root root  3993 Mar 19  2011 README.Debian
> -rw-r--r--   1 root root  7289 Mar 19  2011 README.gz
> -rw-r--r--   1 root root  2493 Mar 19  2011 TODO
> -rw-r--r--   1 root root 14635 Mar 19  2011 TODO.Debian.gz
> -rw-r--r--   1 root root  1396 Mar 19  2011 ULOTKA
> drwxr-xr-x   2 root root   600 Aug 21 02:42 book-en
> drwxr-xr-x   2 root root   760 Aug 21 02:42 book-pl
> -rw-r--r--   1 root root  7130 Nov 14  2011 changelog.Debian.gz
> -rw-r--r--   1 root root 18698 Mar 19  2011 copyright
> -rw-r--r--   1 root root   753 Mar 19  2011 events.txt
> -rw-r--r--   1 root root   854 Mar 19  2011 przenosny-kod.txt
> -rw-r--r--   1 root root  1697 Mar 19  2011 queries.txt
> -rw-r--r--   1 root root  1446 Mar 19  2011 sim.txt
> -rw-r--r--   1 root root   701 Mar 19  2011 voip.txt
> 
> symlinks in /usr/share/doc usually open a can of worms ... dpkg does not
> replace directories with symlinks-to-directories and vice versa, so
> special care needs to be taken on upgrades

Ah, I get it now, ekg2-core ships some of the files in
/usr/share/doc/ekg2, rather than .../ekg2-core,
and ekg2 contains /usr/share/doc/ekg2 that is a symlink.

It's a pity lintian did not complain about this.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685469: ekg2: missing copyright file

[Marcin Owsiany]

On Tue, Aug 21, 2012 at 04:46:21AM +0200, Andreas Beckmann wrote:
> Package: ekg2
> Version: 1:0.3.1-1
> Severity: serious
> Justification: Policy 12.5
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> 
> Hi,
> 
> during a test with piuparts I noticed that your package does not contain
> a copyright file.
> 
> # ls -la /usr/share/doc/ekg2
> total 0
> drwxr-xr-x   2 root root  140 Aug 21 02:42 .
> drwxr-xr-x 154 root root 3580 Aug 21 02:42 ..
> lrwxrwxrwx   1 root root   26 Nov 14  2011 commands-pl.txt -> 
> ../../ekg2/commands-pl.txt
> lrwxrwxrwx   1 root root   25 Nov 14  2011 session-en.txt -> 
> ../../ekg2/session-en.txt
> lrwxrwxrwx   1 root root   25 Nov 14  2011 session-pl.txt -> 
> ../../ekg2/session-pl.txt
> lrwxrwxrwx   1 root root   22 Nov 14  2011 vars-en.txt -> 
> ../../ekg2/vars-en.txt
> lrwxrwxrwx   1 root root   22 Nov 14  2011 vars-pl.txt -> 
> ../../ekg2/vars-pl.txt
> # ls -lad /usr/share/doc/ekg2
> drwxr-xr-x 2 root root 140 Aug 21 02:42 /usr/share/doc/ekg2

Interesting. What architecture is this? This looks different on my TV:

mowsiany@beczulka:~/Desktop/debian/devel/ekg2/uploaded$ dpkg -c 
ekg2_0.3.1-1_amd64.deb |grep doc
drwxr-xr-x root/root 0 2011-03-19 15:04 ./usr/share/doc/
lrwxrwxrwx root/root 0 2011-03-19 15:04 ./usr/share/doc/ekg2 -> 
ekg2-core
mowsiany@beczulka:~/Desktop/debian/devel/ekg2/uploaded$ dpkg -c 
ekg2-core_0.3.1-1_amd64.deb |grep doc/ekg2-core/copy
-rw-r--r-- root/root 18698 2011-03-19 14:57 
./usr/share/doc/ekg2-core/copyright
mowsiany@beczulka:~/Desktop/debian/devel/ekg2/uploaded$ 

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645750: No copyright file

[Marcin Owsiany]

Package: libgadu
version: 1:1.11.0+r1184-1
Severity: serious
Tags: confirmed

For some reason copyright file is missing in the autobuilt packages:
http://lintian.debian.org/maintainer/porridge%40debian.org.html

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#618716: failed armel build of ekg2 1:0.4~pre+20110317.1-1

[Marcin Owsiany]

Package: ekg2
Version: 1:0.4~pre+20110317.1-1
Severity: serious

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
--- Begin Message ---
 * Source package: ekg2
 * Version: 1:0.4~pre+20110317.1-1
 * Architecture: armel
 * State: failed
 * Suite: experimental
 * Builder: arnold.debian.org
 * Build log: 
https://buildd.debian.org/fetch.cgi?pkg=ekg2&arch=armel&ver=1%3A0.4%7Epre%2B20110317.1-1&stamp=1300385434&file=log

Please note that these notifications do not necessarily mean bug reports
in your package but could also be caused by other packages, temporary
uninstallabilities and arch-specific breakages.  A look at the build log
despite this disclaimer would be appreciated however.

--- End Message ---

Bug#608501: ekg2: FTBFS: ENOENT on ekg2-api-docs/usr/share/doc/ekg2-api-docs/

[Marcin Owsiany]

Tags: +pending

On Fri, Dec 31, 2010 at 03:17:48PM +0100, Cyril Brulebois wrote:
> Source: ekg2
> Version: 1:0.3.0~rc4-1
> Severity: serious
> Justification: FTBFS
> 
> Hi,
> 
> your package no longer builds, presumably because buildds run the build
> with -B:

Oops, I had this fixed already for a while, but apparently forgot to
upload! :-D
Doing that now.

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605551: Memory corruption in dcc7 session removal

[Marcin Owsiany]

Package: libgadu3
Version: 1:1.8.0+r592-3
Severity: serious
Tags: upstream fixed-upstream confirmed

A fix for potential segfault was submitted recently to libgadu upstream:
http://toxygen.net/websvn/comp.php?repname=libgadu&path=/&compare[]=/branc...@1022&compare[]=/branc...@1028

Discussed (in Polish) at
http://lists.ziew.org/pipermail/libgadu-devel/2010-November/000672.html

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#546811: poedit: no exit code checks

[Marcin Owsiany]

Package: potool
Version: 0.10-1
Severity: grave

It seems that when recently adding functionality some of the exit code
checks were broken. Also, some exit code checks seem completely missing.

Remember to also check other scripts apart from poedit

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#522108: cruft: reports masses of existing files as missing and even more installed files as unexplained

[Marcin Owsiany]

severity 522108 important
thanks

On Tue, Mar 31, 2009 at 10:48:13PM +0200, Harry Haller wrote:
> Severity: grave
> Justification: renders package unusable

I'd say that "important" is more appropriate here.
Its description explicitly states it is "pre-release".

> cruft: the result is nearly identical: masses of files are reported as
> 'missing' although they exist (as far as I've checked it; mainly from
> /etc, /usr/lib and /usr/share) and even much more files are reported as
> 'unexplained' (also mainly from /etc, /usr/lib and /usr/share).

I agree that a lot of filters are still missing, and the explain scripts
also need a lot of work. Last time I checked, cruft reported no cruft
for a minimal installation (as done by debootstrap).

So it is usable right now for some people (who don't install many
packages and take some effort to create filters for their systems).

> I think, the correct working of cruft is really important for verifying
> the consistence of a system

I would really love for this to be true at some point. Sadly at this
moment, for a real-world desktop installation, if cruft complains about
something it is still more likely to be a missing filter in cruft rather
than actual problem on the system.

> therefore here my frst bug-report. Thanks for reading and eventually
> working on it...

Thanks for the report. Maybe you'll find some time to track down some of
the erroneus reports and file more concrete bugs with patches to fix
them in cruft?

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511342: does not check for file creation errors

[Marcin Owsiany]

Package: devtodo
Version: 0.1.19-3
Severity: grave
Justification: causes data loss

Here's how to reproduce:

| mowsi...@beczulka:/$ strace -t -o /tmp/tda-write-fail.log tda
| Enter text for the item you are adding.
| text> foo
| 1. veryhigh   2. high   3. medium   4. low   5. verylow   
| Enter a priority from those listed above.
| priority> medium
| Index of new item is 1
| todo: warning, created database (.todo) has group or world permissions
| mowsi...@beczulka:/$ echo $?
| 0
| mowsi...@beczulka:/$ ls -l .todo
| ls: .todo: No such file or directory
| mowsi...@beczulka:/$ 

Here's the relevant snippet from the strace log:

| 18:44:52 write(1, "\33[0m\33[32mIndex of new item is 1\33"..., 36) = 36
| 18:44:52 open(".todo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 
EACCES (Permission denied)
| 18:44:52 stat64(".todo", 0xbfe0b304)= -1 ENOENT (No such file or 
directory)
| 18:44:52 write(2, "todo: warning, created database "..., 33) = 33
| 18:44:52 write(2, ".todo", 5)   = 5
| 18:44:52 write(2, ") has group or world permissions", 32) = 32
| 18:44:52 write(2, "\n", 1)  = 1
| 18:44:52 exit_group(0)  = ?

Clearly the exit status nor the message do not reflect the fact that creating
the file failed, though apparently the program does pay attention to the fact
that open() failed, as there is no write() call visible.

Apart from the above, it would be good to check if the program correctly
detects write(), flush() and close() failures (e.g. when filesystem runs out of
space).

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#506951: Dia fails to install on sparc

[Marcin Owsiany]

Package: dia
Version: 0.96.1-7.1
Severity: grave

Hi, dia fails to install on the sparc autobuilder, making my package
(cruft) unbuildable. Can you have a look at this? Please see the
attached message from buildd maintainer, which has a link to build log.

It might in fact be a bug in dia's dependencies. Please clone/reassign
appropriately.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
--- Begin Message ---
Hi, 

On Tue Nov 25, 2008 at 13:35:21 +0000, Marcin Owsiany wrote:
> Hi,
> 
> Cruft 0.9.12 built on all architectures except sparc, due to dia's (its
> build dep) dependencies "not going to be installed":
> http://buildd.debian.org/fetch.cgi?&pkg=cruft&ver=0.9.12&arch=sparc&stamp=1227352631&file=log
> 
> Can something be done about this problem?

yes, fixing the dependencies of dia.

Greetings
Martin

-- 
 Martin Zobel-Helas <[EMAIL PROTECTED]>  | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870

--- End Message ---

Bug#475130: Some more info..

[Marcin Owsiany]

On Mon, May 05, 2008 at 11:56:51AM -0700, Mike Markley wrote:
> If this header is actually being eaten by the smfi_chgheader() then it
> is a bug in the Postfix Milter implementation.

Could be. I guess that one way to verify this theory is to write a very
basic milter which would just try to reproduce this bug. If that one
also causes such behavior, then it would be the ideal thing to submit to
postfix maintainers as a bug report.

Unfortunately I know very little about milter APIs.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#480777: [ekg2-devel] [EMAIL PROTECTED]: Bug#480777: ekg2_20080511+1713-1(hppa/experimental): FTBFS: undefined reference to `mutt_convert_string']

[Marcin Owsiany]

On Tue, May 13, 2008 at 01:21:14PM +0200, Jakub Zawadzki wrote:
> On Tue, May 13, 2008 at 11:56:26AM +0100, Marcin Owsiany wrote:
> > On Mon, May 12, 2008 at 11:00:12AM +0100, Marcin Owsiany wrote:
> > > Hi all, I got the following bug report. Not sure what's the particular
> > > difference between i386 and hppa that causes problems, but maybe someone
> > > has some ideas?
> > 
> > [...]
> > 
> > > Full build log(s): 
> > > http://experimental.ftbfs.de/build.php?&ver=20080511+1713-1&pkg=ekg2&arch=hppa
> > 
> > Among other things, this contained:
> > 
> > stuff.c: In function 'mutt_convert_string':
> > stuff.c:2915: warning: 'mutt_iconv' is static but used in inline function 
> > 'mutt_convert_string' which is not static
> >
> 
> This is like: 
> http://ml.ziew.org/mailman/pipermail/ekg2-users/2008-April/001240.html 
> (sorry, polish only) 
> 
> I think it's new feature of gcc-4.3... when gcc-4.3 sees inline function
> it automagicly add static keyword..
> (I didn't make any research on this, anyone?)

The following may be useful in understanding what is going on:
http://gcc.gnu.org/gcc-4.3/porting_to.html
http://gcc.gnu.org/onlinedocs/gcc/Inline.html

> I think we should move all inline function (without static keyword) from
> *.c to *.h or remove inline keyword.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#480779: Reassigning to ruby1.8-dev

[Marcin Owsiany]

reassign 480779 ruby1.8-dev 1.8.6.114-2
thanks

After actually looking at the compiler message, I can see that it seems
to be an error in ruby's include file. Let me know if you feel
otherwise, otherwise please ignore this report.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#478821: non-idempotent code in postinst

[Marcin Owsiany]

On Wed, May 07, 2008 at 08:51:05AM +0200, Adrian von Bidder wrote:
> I added the statoverride things because IIRC I had problems with the dir 
> premissions being reset somehow, but I'm not clear on why/how.
> 
> (You can tell I'm not that an experienced packager, can't you :-)
> 
> So removing the statoverride logic is fine by me, however I'm quite swamped 
> now and would be very happy for a patch (or NMU since this is apparently 
> RC.)

I'm just about to NMU 1.31-2.1 with the following change:


--- postgrey-1.31/debian/postinst
+++ postgrey-1.31/debian/postinst
@@ -14,8 +14,9 @@
 getent group postgrey > /dev/null || \
 addgroup --system postgrey

-if [ ! -e "$DBDIR" ]; then
-mkdir -p "$DBDIR"
+install -d -o postgrey -g postgrey -m 0700 "$DBDIR"
+
+   if ! dpkg-statoverride --list "$DBDIR" > /dev/null 2>&1 ; then
 dpkg-statoverride --update --add \
 postgrey postgrey 0700 "$DBDIR"
 fi


While I still think that dpkg-statoverride should not be needed, I decided to
keep it as NMU is not a place to deal with such things, especially when
"mysterious permission resets", which I know nothing about, are in question.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#478821: non-idempotent code in postinst

[Marcin Owsiany]

On Wed, May 07, 2008 at 08:51:05AM +0200, Adrian von Bidder wrote:
> I added the statoverride things because IIRC I had problems with the dir 
> premissions being reset somehow, but I'm not clear on why/how.
> 
> (You can tell I'm not that an experienced packager, can't you :-)
> 
> So removing the statoverride logic is fine by me, however I'm quite swamped 
> now and would be very happy for a patch (or NMU since this is apparently 
> RC.)

I will have a closer look at it, to make sure I don't break things even
if some older version did ship $DBDIR in the package

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#475130: Some more info..

[Marcin Owsiany]

On Sat, May 03, 2008 at 07:39:17PM -0700, Mike Markley wrote:
> It seems more likely to me that the Received header is somehow being
> suppressed (it should be inserted by the host that's running spfmilter,
> right?)

No. It is removing the most recent Received header which is _already_ in
the received message (i.e. the header added by the MTA which directly
preceded the problematic one on the message's path).

> I still don't understand how spfmilter could be causing this, so I plan
> to take it to postfix-users or similar. Based on the spfmilter package
> version, I'm guessing you're running etch, and therefore Postfix 2.3.8;
> can you confirm that?

My guess would be that the API does not work like spfmilter assumes it
does. I don't know where the bug lies, though.

Yes, I am using etch, postfix 2.3.8-2

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#478821: non-idempotent code in postinst

[Marcin Owsiany]

Package: postgrey
Version: 1.27-4
Severity: serious

The following bit is not idempotent:

|if [ ! -e "$DBDIR" ]; then
|mkdir -p "$DBDIR"
|dpkg-statoverride --update --add \
|postgrey postgrey 0700 "$DBDIR"
|fi

This will not do the right thing if for any reason dpkg-statoverride fails to
run on the first try. It also happens to make it hard to have $DBDIR
bind-mounted from somewhere else.

Please break this block into two parts, one to check directory exinstance and
creation, and another to fix and register permissions. Actualy, why do you need
the dpkg-statoverride call anyway? The directory does not seem to be included
in the package.. Maybe just "install -d -o -g -m" it?

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (100, 'proposed-updates'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6b-ovz-686
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#475130: Some more info..

[Marcin Owsiany]

Yes, I do get the "spoofed header" warnings with the problematic messages. And
no, I did not change the HEADER_NAME macro in source code :-)

Here are the config snippets:

main.cf:
---
smtpd_milters =
inet:127.0.0.1:12345,
#   unix:/var/run/dkim-filter/dkim-filter.sock,
unix:/var/run/clamav/clamav-milter.ctl
milter_default_action = accept
---

/etc/default/spfmilter:
---
DAEMON_OPTS="-l a:master.debian.org"
NO_MACROS_CHECK=1
SOCKET="inet:[EMAIL PROTECTED]" # listen just on loopback on port 12345
---

If you'd like to see complete configs, I can send them to you privately.

The only other non-standard thing I can think of is libspf0, patched for
#392927 and #464029 (interdiff attached), but I don't think this matters.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
diff -u libspf-0.999-1.0.0-p3/debian/changelog libspf-0.999-1.0.0-p3/debian/changelog
--- libspf-0.999-1.0.0-p3/debian/changelog
+++ libspf-0.999-1.0.0-p3/debian/changelog
@@ -1,3 +1,10 @@
+libspf (0.999-1.0.0-p3-3.0.sl.1) unstable; urgency=low
+
+  * Patched to avoid #392927
+  * Patched to avoid #464029
+
+ -- Marcin Owsiany <[EMAIL PROTECTED]>  Thu, 13 Mar 2008 13:41:00 +
+
 libspf (0.999-1.0.0-p3-3) unstable; urgency=low
 
   * Fixed debian/rules file syntax (closes: #353857)
only in patch2:
unchanged:
--- libspf-0.999-1.0.0-p3.orig/src/libspf/main.c
+++ libspf-0.999-1.0.0-p3/src/libspf/main.c
@@ -1683,7 +1683,8 @@
 xfree(p->from);
   }
 
-  if (p->spf_rlevel > 0)
+  if ((p->spf_rlevel > 0) &&
+  (p->current_domain != p->original_domain))
   {
 xfree(p->current_domain);
   }
@@ -1830,6 +1831,11 @@
   xvprintf("local-part: [%s]; domain: [%s]; sender: [%s]\n",
 p->local_part, p->current_domain, p->from);
 
+  /*
+   * We need to reset this, otherwise we'll hit the recursion limit after N rejected MAIL FROMs.
+   */
+  p->spf_rlevel = 0;
+
   return(SPF_TRUE);
 }
 
only in patch2:
unchanged:

Bug#475130: Followup

[Marcin Owsiany]

It seems to be a bug in the code that removes duplicate Received-SPF
headers, because the Received header is properly retained when I send
the message from another host.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#475130: eats first Received header

[Marcin Owsiany]

Package: spfmilter
Version: 1.99+0.97-1
Severity: grave
Justification: causes data loss and violates a MUST directive of RFC2821

Here's a diff between a two otherwise identical messages (IDs and dates
replaced with constants for easy diffing), one with spfmilter disabled,
the other with enabled.


| --- t32008-04-09 09:55:19.0 +0100
| +++ t22008-04-09 09:55:19.0 +0100
| @@ -1,42 +1,39 @@
|  From [EMAIL PROTECTED] date
|  Return-path: <[EMAIL PROTECTED]>
|  Envelope-to: [EMAIL PROTECTED]
|  Delivery-date: date
|  Delivered-To: [EMAIL PROTECTED]
| +Received-SPF: none (mail.vicoop.com: [EMAIL PROTECTED] does not designate 
permitted sender hosts) receiver=mail.vicoop.com; client-ip=70.103.162.29; 
helo=master.debian.org; [EMAIL PROTECTED]; x-software=spfmilter 0.97 
http://www.acme.com/software/spfmilter/ with libspf-unknown;
|  Received: from mail0.vicoop.com [85.17.210.107]
|   by beczulka with POP3 (fetchmail-6.3.6)
|   for <[EMAIL PROTECTED]> (single-drop); date
|  Received: from master.debian.org (master.debian.org [70.103.162.29])
|   by mail.vicoop.com (Postfix) with ESMTP id ID
|   for <[EMAIL PROTECTED]>; date
| -Received: from mail0.vicoop.com ([85.17.210.107] helo=mail.vicoop.com)
| - by master.debian.org with esmtp (Exim 4.63)
| - (envelope-from <[EMAIL PROTECTED]>)
| - id ID
| - for [EMAIL PROTECTED]; date
| +Received-SPF: pass (mail.vicoop.com: authenticated connection) 
receiver=mail.vicoop.com; client-ip=82.10.150.33; helo=beczulka; [EMAIL 
PROTECTED]; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ 
with libspf-unknown;
|  Received: from beczulka (cpc2-seve11-0-0-cust544.popl.cable.ntl.com 
[82.10.150.33])
|   (Authenticated sender: [EMAIL PROTECTED])
|   by mail.vicoop.com (Postfix) with ESMTP id ID
|   for <[EMAIL PROTECTED]>; date
|  Received: from porridge by beczulka with local (Exim 4.63)
|   (envelope-from <[EMAIL PROTECTED]>)
|   id ID
|   for [EMAIL PROTECTED]; date
|  Date: date
|  From: Marcin Owsiany <[EMAIL PROTECTED]>
|  To: [EMAIL PROTECTED]
| -Subject: t3
| -Message-ID: <[EMAIL PROTECTED]>
| +Subject: t2
| +Message-ID: <[EMAIL PROTECTED]>
|  MIME-Version: 1.0
|  Content-Type: text/plain; charset=us-ascii
|  Content-Disposition: inline
|  User-Agent: Mutt/1.5.13 (2006-08-11)
|  Status: RO
|  Content-Length: 154
|  Lines: 4
|  
|  
|  -- 
|  Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
|  GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

mail0.vicoop.com (which is the host I'm debugging) acted both as a
smarthost for beczulka, and as the intermediate destination for the
message (subsequently fetched by beczulka).

Notice how the "Received" line added by master.debian.org got eaten by
mail0. I'm 100% certain that master did send the Received header,
because I sniffed the SMTP dialogue.

Interestingly, the Received header added by beczulka did NOT get eaten
when the message got relayed by mail0 for the first time. This suggests
that the header only gets eaten when the status is "none" but not when
it's "pass".

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6b-ovz-686
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)

Versions of packages spfmilter depends on:
ii  adduser3.102 Add and remove users and groups
ii  libc6  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  libmilter0 8.13.8-3  Sendmail Mail Filter API (Milter)
ii  libspf00.999-1.0.0-p3-3  the ANSI C SPF reference library (

spfmilter recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#470962: Incompatible with post-DSA-1428 kernel source

[Marcin Owsiany]

Package: kernel-patch-openvz
Version: 028.18.1etch5
Severity: grave

One of the patches for CVE-2007-3104 in DSA-1428-1 (incorrectly called
1481-1 in its subject), uploaded in linux-2.6_2.6.18.dfsg.1-13etch5
introduced an incompatibility with the openvz patch.

Attached is a patch which makes the patch work. I've been using it in my
packages since December, so I consider it rather well tested. Sorry for
the delayed filing of this bug.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
--- linux-2.6-2.6.18.dfsg.1/debian/patches/debian/ovz-028.18-deb.patch
+++ linux-2.6-2.6.18.dfsg.1/debian/patches/debian/ovz-028.18-deb.patch
@@ -50983,9 +50983,9 @@
  extern kmem_cache_t *sysfs_dir_cachep;
  
  extern struct inode * sysfs_new_inode(mode_t mode, struct sysfs_dirent *);
-@@ -21,7 +30,6 @@ extern void sysfs_drop_dentry(struct sys
- extern int sysfs_setattr(struct dentry *dentry, struct iattr *iattr);
+@@ -31,7 +31,6 @@ extern int sysfs_setattr(struct dentry *
  
+ extern spinlock_t sysfs_lock;
  extern struct rw_semaphore sysfs_rename_sem;
 -extern struct super_block * sysfs_sb;
  extern const struct file_operations sysfs_dir_operations;

Bug#424449: Info received (Some info from gdb)

[Marcin Owsiany]

Sorry, wrong bug number! Please ignore my previous message.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#424449: Some info from gdb

[Marcin Owsiany]

I ran a test similar to the one in original report with spfmilter
running under gdb. I set a breakpoint and investigated the ld->peer_info
structure contents at the moment when SPF_policy_main() is about to get
called from lib_do_check (spfmilter.c:1776).

Comparison of the structure contents between the call on first MAIL FROM
(which will get rejected) and the last MAIL FROM (i.e. the incorrectly
accepted one), reveals that there is a difference in the value of the
structure's "spf_rlevel" member.

Namely, "spf_rlevel = 1" on the first MAIL FROM, and "spf_rlevel = 9"
just before the last one.

My strong suspicion is that libspf treats it as reaching some maximum
(=10?) recursion level and fails back to accepting the sender. I don't
yet know whether not resetting the structure correctly is libspf's
fault, or spfmilter's fault.

I may have a look tomorrow, it's late now.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#456722: Removal of xmms and its reverse-dependancies - what is the status?

[Marcin Owsiany]

An xmms rev-dep I maintain (xmms-xf86audio) is useless without xmms, and
not really portable to any of its replacements. Therefore I agree it
should be removed if xmms is removed. However:

 - the reporter said to ask for removal after xmms is removed
 - the ftpmaster removal wiki page says reverse-dependancies should
   usually be removed first.
 - #461309 (against ftp.debian.org) is tagged moreinfo
 - the thread mentioned in #461309 is dead

So what's the status? Is xmms removal decided yet, or not? Should I ask
for xmms-xf86audio removal now, or wait?

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#444472: does not apply to linux-2.6 2.6.18.dfsg.1-13etch3

[Marcin Owsiany]

Package: kernel-patch-openvz
Version: 028.18.1etch4
Severity: grave
Tags: patch

The security updates present in 2.6.18.dfsg.1-13etch3 conflict with two
hunks of the openvz patch.

The attached patch is sufficient to make it apply, athough the line
numbers could use some adjustment..


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)

Versions of packages kernel-patch-openvz depends on:
ii  bash  3.1dfsg-8  The GNU Bourne Again SHell
ii  grep-dctrl2.9.3  Grep Debian package information - 
ii  patch 2.5.9-4Apply a diff file to an original

kernel-patch-openvz recommends no packages.

-- no debconf information
--- diff-ovz-028.18-deb	2007-09-28 22:23:16.0 +0100
+++ ovz-028.18-deb.patch	2007-09-28 22:22:48.0 +0100
@@ -46105,15 +46105,15 @@
 diff -uprN linux-source-2.6.18/fs/jffs2/acl.h linux-source-2.6.18-ovz/fs/jffs2/acl.h
 --- linux-source-2.6.18/fs/jffs2/acl.h	2006-09-20 07:42:06.0 +0400
 +++ linux-source-2.6.18-ovz/fs/jffs2/acl.h	2007-03-09 17:52:50.0 +0300
-@@ -27,7 +27,8 @@ struct jffs2_acl_header {
- 
+@@ -28,7 +28,8 @@
  #define JFFS2_ACL_NOT_CACHED ((void *)-1)
  
+ extern struct posix_acl *jffs2_get_acl(struct inode *inode, int type);
 -extern int jffs2_permission(struct inode *, int, struct nameidata *);
 +extern int jffs2_permission(struct inode *, int, struct nameidata *,
 +		struct exec_perm *perm);
  extern int jffs2_acl_chmod(struct inode *);
- extern int jffs2_init_acl(struct inode *, struct inode *);
+ extern int jffs2_init_acl(struct inode *, struct posix_acl *);
  extern void jffs2_clear_acl(struct jffs2_inode_info *);
 diff -uprN linux-source-2.6.18/fs/jfs/acl.c linux-source-2.6.18-ovz/fs/jfs/acl.c
 --- linux-source-2.6.18/fs/jfs/acl.c	2006-09-20 07:42:06.0 +0400
@@ -114491,9 +114491,9 @@
  	if (charged)
  		vm_unacct_memory(charged);
  	return error;
-@@ -1492,12 +1518,16 @@ static int acct_stack_growth(struct vm_a
- 			return -ENOMEM;
- 	}
+@@ -1525,12 +1525,16 @@
+ 	if (is_hugepage_only_range(vma->vm_mm, new_start, size))
+ 		return -EFAULT;
  
 +	if (ub_memory_charge(mm, grow << PAGE_SHIFT, vma->vm_flags,
 +vma->vm_file, UB_SOFT))
@@ -114505,7 +114505,7 @@
  	 */
  	if (security_vm_enough_memory(grow))
 -		return -ENOMEM;
-+		goto fail_sec;
++		goto fail_charge;
  
  	/* Ok, everything looks good - let it rip */
  	mm->total_vm += grow;

Bug#431721: [EMAIL PROTECTED]: Re: security.d.o packages for etch built on sarge]

[Marcin Owsiany]

Just for the record - a fix has been bin-NMU'ed but is not available for
automatic upgrade yet. See the URL in the attachment.

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
--- Begin Message ---
On Mon, Jul 02, 2007 at 07:27:13PM +0200, Moritz Muehlenhoff wrote:
> Marcin Owsiany wrote:
> > > Why I haven't realized you're talking about my package up till now is a
> > > mystery to me. I'll check this ASAP.
> > 
> > Indeed, it looks like I used wrong pbuilder tarball to build this one
> > :-(
> > 
> > Security team: this just needs a rebuild, but how exactly should I fix
> > this? Can I do a bin-nmu so that other architectures don't need a
> > rebuild? Or should I just prepare 1:1.7~rc2-1etch2 as a new revision and
> > upload that?
> 
> A binNMU has been done, a package is available at
> http://debian.netcologne.de/debian/pool/main/e/ekg/ekg_1.7~rc2-1etch1+b1_i386.deb
> 
> It will also be part of the immediate stable point update.

As far as I can see, it has not been uploaded to etch-security, which
means it will only become available after the next point release. Can we
do anything to speed this up?

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


signature.asc
Description: Digital signature
--- End Message ---

Bug#433345: please rebuild to follow libglib1.2's ldbl transition

[Marcin Owsiany]

Package: xmms
Version: 1:1.2.10+20061101-1etch1
Severity: grave

xmms is currently uninstallable because libglib1.2 changed into
libglib1.2ldbl

Please rebuild and upload so that I can do the same with xmms-xf86audio


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686-mactel
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)

Versions of packages xmms depends on:
ii  libasound21.0.13-2   ALSA library
ii  libaudiofile0 0.2.6-6Open-source version of SGI's audio
ii  libc6 2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libesd0   0.2.36-3   Enlightened Sound Daemon - Shared 
ii  libgl1-mesa-glx [libgl1]  6.5.1-0.6  A free implementation of the OpenG
ii  libglib1.21.2.10-17  The GLib library of C routines
ii  libgtk1.2 1.2.10-18  The GIMP Toolkit set of widgets fo
ii  libice6   1:1.0.1-2  X11 Inter-Client Exchange library
ii  libmikmod23.1.11-a-6 A portable sound library
ii  libogg0   1.1.3-2Ogg Bitstream Library
ii  libsm61:1.0.1-3  X11 Session Management library
ii  libvorbis0a   1.1.2.dfsg-1.2 The Vorbis General Audio Compressi
ii  libvorbisfile31.1.2.dfsg-1.2 The Vorbis General Audio Compressi
ii  libx11-6  2:1.0.3-7  X11 client-side library
ii  libxext6  1:1.0.1-2  X11 miscellaneous extension librar
ii  libxi61:1.0.1-4  X11 Input extension library
ii  libxxf86vm1   1:1.0.1-2  X11 XFree86 video mode extension l
ii  zlib1g1:1.2.3-13 compression library - runtime

Versions of packages xmms recommends:
ii  unzip 5.52-9 De-archiver for .zip files

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429252: ekg2_20070619+1215-1(experimental/alpha/ds10): main.c:492: error: incompatible type for argument 2 of 'va_format_string'

[Marcin Owsiany]

On Thu, Jun 21, 2007 at 01:01:30PM +0200, Marc 'HE' Brockschmidt wrote:
> found 429252
> thanks
> 
> Heya,
> 
> Your last upload only moved the problem:

More correctly: fixed only some occurences.

Unfortunately I have no access to any alpha machine so the only way for
me to test this is to upload a new version.

> | Automatic build of ekg2_20070619+1215-1 on ds10 by sbuild/alpha 98-farm
> | Build started at 20070621-0329
> | 
> **
> 
> [...]
> 
> |  alpha-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -fvisibility=hidden -g 
> -O2 -Wall -std=c99 -MT logs_la-main.lo -MD -MP -MF .deps/logs_la-main.Tpo -c 
> main.c  -fPIC -DPIC -o .libs/logs_la-main.o
> | main.c: In function 'logs_print_window':
> | main.c:492: error: incompatible type for argument 2 of 'va_format_string'

I just uploaded 20070621+1337-1 which fixes this one.
I guess tomorrow we'll see if there are more..

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429252: ekg2_20070305+1821-1(experimental/alpha/ds10): main.c:625: error: incompatible type for argument 2 of 'logs_setvar_default'

[Marcin Owsiany]

On Sat, Jun 16, 2007 at 04:49:43PM +0200, Marc 'HE' Brockschmidt wrote:
> Package: ekg2
> Version: 20070305+1821-1
> Severity: serious
> Tags: experimental
> 
> Heya,
> 
> Your package fails to build:

I just uploaded ekg2_20070619+1215-1 which contains a potential fix. Can
you schedule it to be tried on alpha soon so we know whether it's OK
now?

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


signature.asc
Description: Digital signature

Bug#398194: shows just an outline filled with solid white colour

[Marcin Owsiany]

Package: xteddy
Version: 2.1-1
Severity: grave

Having just an outline of a teddy is definitely not fun :-(
See http://owsiany.pl/tmp/2006-11-12-bug-xteddy.png
Specifying -wm does not help.
I don't know whether that matters, but I'm using GNOME.
Let me know if I can do anything more to debug this.

Marcin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-xen-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

Versions of packages xteddy depends on:
ii  imlib11 1.9.14-31Imlib is an imaging library for X 
ii  libc6   2.3.6.ds1-3  GNU C Library: Shared libraries
ii  libice6 1:1.0.0-3X11 Inter-Client Exchange library
ii  libjpeg62   6b-13The Independent JPEG Group's JPEG 
ii  libpng12-0  1.2.8rel-5.2 PNG library - runtime
ii  libsm6  1:1.0.0-4X11 Session Management library
ii  libtiff43.8.2-6  Tag Image File Format (TIFF) libra
ii  libungif4g  4.1.4-2  shared library for GIF images (run
ii  libx11-62:1.0.0-8X11 client-side library
ii  libxext61:1.0.0-4X11 miscellaneous extension librar
ii  zlib1g  1:1.2.3-13   compression library - runtime

xteddy recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#386299: Is lack of UTF support an RC bug? [was: Bug#386299: ekg2: Plugin/program compilation option mismatch]

[Marcin Owsiany]

On Thu, Sep 07, 2006 at 02:46:16AM -0700, Steve Langasek wrote:
> severity 386299 serious
> thanks
> 
> On Wed, Sep 06, 2006 at 06:14:55PM +0100, Marcin Owsiany wrote:
> 
> > Unicode support in ekg2 is highly experimental and not yet supported
> > upstream, therefore the debian package is built without UTF-8 support.
> 
> > On Wed, Sep 06, 2006 at 05:56:17PM +0200, Tristan Seligmann wrote:
> > > Attempting to run ekg2 yields the following:
> 
> > Try running it in some iso-8859 locale.
> 
> That's not an acceptable answer, given that almost all locales for etch will
> be Unicode by default.  This makes the package unreleasable.  Of course, the
> package seems to only be in experimental at all, so I don't see why you
> would bother to downgrade the bug...

It doesn't matter for ekg2, which will stay in experimental for quite a
while I'm afraid, but it is important for at least two other of my
packages (which are in etch) which don't support UTF-8 at all. And I'm
reasonably sure they are not the only packages in etch which don't
support UTF.

Who decided that we should just drop them all? After all generating a
non-UTF locale and setting an environment variable isn't a very
difficult workaround? I mean, when has lack of UTF support become an
RC-bug? Charset support is not even mentioned in the policy, other than
for debian/changelog.

Don't get me wrong, I'm not against UTF-8, but just dropping everything
that doesn't support it, without a former warning, sounds ridiculous.

regards,

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


signature.asc
Description: Digital signature

Bug#386299: ekg2: Plugin/program compilation option mismatch

[Marcin Owsiany]

severity 386299 minor
retitle 386299 Fails when run in UTF-8 environment
thanks

Unicode support in ekg2 is highly experimental and not yet supported
upstream, therefore the debian package is built without UTF-8 support.

On Wed, Sep 06, 2006 at 05:56:17PM +0200, Tristan Seligmann wrote:
> Attempting to run ekg2 yields the following:

Try running it in some iso-8859 locale.

> plugin ncurses cannot be loaded because of mishmashed compilation...
> program compilated with: --enable-unicode
>  plugin compilated with: --disable-unicode

This is not true, everything was built without unicode support. The
messages need to be fixed.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362882: Patch, NMU coming

[Marcin Owsiany]

tags 362882 + patch pending
thanks

Attaching a patch to fix this bug. Tested with ekg2, seems to work fine.

I'm uploading an NMU in a few minutes, since this is blocking my upload
of ekg2. I hope Philipp doesn't mind, since he said OK with #318150,
which was quite similar.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
diff -u xosd-2.2.14/debian/changelog xosd-2.2.14/debian/changelog
--- xosd-2.2.14/debian/changelog
+++ xosd-2.2.14/debian/changelog
@@ -1,3 +1,12 @@
+xosd (2.2.14-1.3) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Deleted packages removed during X.org 7 transition from build-deps and
+-dev package deps, added x11proto-core-dev, x11proto-xinerama-dev and
+x11proto-xext-dev to build-deps for some headers (Closes: #362882)
+
+ -- Marcin Owsiany <[EMAIL PROTECTED]>  Thu, 27 Apr 2006 21:03:37 +0100
+
 xosd (2.2.14-1.2) unstable; urgency=high
 
   * Non-maintainer upload.
diff -u xosd-2.2.14/debian/control xosd-2.2.14/debian/control
--- xosd-2.2.14/debian/control
+++ xosd-2.2.14/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Philipp Matthias Hahn <[EMAIL PROTECTED]>
-Build-Depends: libgtk1.2-dev, xmms-dev (>= 1.2.0-1), libtool, debhelper (>= 
4.1.0), libgdk-pixbuf-dev, libx11-dev, libxext-dev, xlibs-static-pic, 
libxinerama-dev, cdbs
+Build-Depends: libgtk1.2-dev, xmms-dev (>= 1.2.0-1), libtool, debhelper (>= 
4.1.0), libgdk-pixbuf-dev, libx11-dev, libxext-dev, x11proto-core-dev, 
x11proto-xinerama-dev, x11proto-xext-dev, libxinerama-dev, cdbs
 Build-Conflicts: libxosd-dev (<< ${Source-Version})
 Standards-Version: 3.6.1.1
 
@@ -21,7 +21,7 @@
 Package: libxosd-dev
 Section: libdevel
 Architecture: any
-Depends: libxosd2 (= ${Source-Version}), libx11-dev, libxext-dev, x-dev, 
xlibs-static-dev, xlibs-static-pic, ${shlibs:Depends}, libxinerama-dev
+Depends: libxosd2 (= ${Source-Version}), libx11-dev, libxext-dev, 
${shlibs:Depends}, libxinerama-dev
 Conflicts: libxosd
 Description: X On-Screen Display library - development
  A library for displaying a TV-like on-screen display in X.

Bug#355257: /token causes exit(), impossible to retrieve tokens

[Marcin Owsiany]

Package: ekg
Version: 1:1.5+20050411-5
Severity: serious
Tags: pending upstream fixed-upstream sarge

English summary:
Tokens are needed for things like registering new accounts. A change
from JPEG to GIF tokens on GG servers causes ekg to exit() from libjpeg
routines (no proper error handling).
Though it is possible to disable jpeg parsing, but due to a bug in ekg,
no information about token is available then (token file is deleted),
rendering /token a "no-op".
Since this is an important functionality, I consider this bug RC.

On Fri, Mar 03, 2006 at 08:21:04PM +0100, sumar wrote:
> Debian Sarge, wersja ekg: 1.5+20050411-5.
> 
> Po wpisaniu komendy "token" ekg wyłącza się. W najnowszej wersji ze strony
> projektu nie ma tego błędu. Prawdopodobnie jest to związane ze zmianą
> obsługi tokenów w Gadu-Gadu. 

Owszem.

set display_token 0

zapobiega wyłączeniu, ale nie powoduje pokazywania nazwy pliku z
tokenem.

Spróbuję zrobić pakiet do sarge-proposed-updates, albo volatile

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]>  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
"Every program in development at MIT expands until it can read mail."
  -- Unknown


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332842: ekg2: FTBFS: ls: libltdl/*: No such file or directory

[Marcin Owsiany]

On Sun, Oct 30, 2005 at 04:42:46PM +0100, Kurt Roeckx wrote:
> On Mon, Oct 31, 2005 at 02:22:58AM +1100, Rob Weir wrote:
> > On Sun, Oct 09, 2005 at 12:12:38AM +0200, Kurt Roeckx said
> > > Hi,
> > > 
> > > Your package is failing to build.
> > > 
> > > >From the log:
> > > Running libtoolize...
> > > ls: libltdl/*: No such file or directory
> > > [...]
> > > make[3]: Entering directory `/build/buildd/ekg2-20050713+2142/libltdl'
> > > make[3]: *** No rule to make target `all'.  Stop.
> > > make[3]: Leaving directory `/build/buildd/ekg2-20050713+2142/libltdl'
> > > make[2]: *** [all-recursive] Error 1
> > > 
> > > The last libtool update changed the pacakge so that if you run
> > > libtoolize with the --ltdl option that you require to
> > > build-depend on the libltdl3-dev package instead.
> > > 
> > > It would be a good idea to build depend on the libltdl3-dev
> > > package in any case, and make sure it gets linked to the debian
> > > package instead of using an internal static copy.
> > 
> > Hm, I can't reproduce this in a current sid chroot.
> 
> Are you sure you removed the libltdl3-dev package?  This error
> will only show up if you don't have it installed.  And you should
> add a build dependency to make sure you have it installed.
> 
> Anyway, upstream libtool has just applied a patch that should
> give a better error message next time.

Moreover, ekg2 upstream has removed libtool support, so this should be
a non-issue when I get the time to package a current snapshot.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319490: FTBFS in experimental

[Marcin Owsiany]

tags 319490 +pending
thanks

On Fri, Jul 22, 2005 at 04:29:40PM +0200, Andreas Barth wrote:
> please do not include .o-files into your uploads:
> [EMAIL PROTECTED]:~$ tar tzf pool/main/c/cruft/cruft_0.9.6-0.6.tar.gz | grep 
> \\.o$
> cruft-0.9.6/shellexp.o

Oops, forgot to add a clean command for this new file.

> this is wrong.

The package is ready, I will upload as soon as ftp-master goes back
online.

> Also, as cruft is non debian native,

What makes you think it is not debian native? The -0.x debian revision
is recommended by developers' reference for NMUs of packages without
debian revision.

> please use the
> appropriate source package format for it.
> 
> please see http://experimental.ftbfs.de/build.php?arch=&pkg=cruft
> for the full build log

FYI: Unable to connect to remote host: Connection refused

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#318970: Integer overflow in libgadu

[Marcin Owsiany]

Package: ekg
Version: 1.5+20050411-4
Severity: grave
Tags: pending, security

This is potentially a remote arbitrary code execution

http://cvs.toxygen.net/ekg/lib/libgadu.c.diff?r1=1.147&r2=1.148&f=u
http://cvs.toxygen.net/ekg/lib/events.c.diff?r1=1.95&r2=1.96&f=u

This is also present in versions in testing/sid (including 
1.5+20050712+1.6rc2-1)

It is fixed upstream in 1.6rc3

I will prepare uploads now.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#318150: linker cannot find -lXinerama_pic

[Marcin Owsiany]

tags 318150 +patch
thanks

On Wed, Jul 13, 2005 at 04:28:14PM -0700, Steve Langasek wrote:
> On Wed, Jul 13, 2005 at 10:16:30PM +0300, Marcin Owsiany wrote:
> > Package: libxosd-dev
> > Severity: grave
> 
> > It seems that with the new Xorg in sid, Xinerama_pic.a got lost
> > somewhere. It doesn't seem to be neither in xlibs-static-pic nor in
> > libxinerama* packages. As a consequence, linker does not work with what
> > xosd-cofig --libs produces, rendering the package unusable.
> 
> Yes, this is now a shared library in the libxinerama* packages, so there's
> no need for a _pic.a anymore.  The package should be updated to use
> -lXinerama instead of -lXinerama_pic.

Apparently the autostuff already has support for this, so adding
libxinerama-dev to dependancies and a rebuild are sufficient (i.e. they
work for me to build ekg2).

I'm attaching a patch. I intend to NMU - waiting the usual period is
quite unconvenient for me (I cannot upload ekg2), so I would appreciate
an authorization from Philipp ASAP.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
diff -u xosd-2.2.14/debian/changelog xosd-2.2.14/debian/changelog
--- xosd-2.2.14/debian/changelog
+++ xosd-2.2.14/debian/changelog
@@ -1,3 +1,11 @@
+xosd (2.2.14-1.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Rebuilt to catch new Xinerama.so from x.org (Closes: #318150)
+  * Added libxinerama-dev to build-deps and -dev package deps
+
+ -- Marcin Owsiany <[EMAIL PROTECTED]>  Thu, 14 Jul 2005 14:48:26 +0300
+
 xosd (2.2.14-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -u xosd-2.2.14/debian/control xosd-2.2.14/debian/control
--- xosd-2.2.14/debian/control
+++ xosd-2.2.14/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Philipp Matthias Hahn <[EMAIL PROTECTED]>
-Build-Depends: libgtk1.2-dev, xmms-dev (>= 1.2.0-1), libtool, debhelper (>= 
4.1.0), libgdk-pixbuf-dev, libx11-dev, libxext-dev, xlibs-static-pic, cdbs
+Build-Depends: libgtk1.2-dev, xmms-dev (>= 1.2.0-1), libtool, debhelper (>= 
4.1.0), libgdk-pixbuf-dev, libx11-dev, libxext-dev, xlibs-static-pic, 
libxinerama-dev, cdbs
 Build-Conflicts: libxosd-dev (<< ${Source-Version})
 Standards-Version: 3.6.1.1
 
@@ -21,7 +21,7 @@
 Package: libxosd-dev
 Section: libdevel
 Architecture: any
-Depends: libxosd2 (= ${Source-Version}), libx11-dev, libxext-dev, x-dev, 
xlibs-static-dev, xlibs-static-pic, ${shlibs:Depends}
+Depends: libxosd2 (= ${Source-Version}), libx11-dev, libxext-dev, x-dev, 
xlibs-static-dev, xlibs-static-pic, ${shlibs:Depends}, libxinerama-dev
 Conflicts: libxosd
 Description: X On-Screen Display library - development
  A library for displaying a TV-like on-screen display in X.

Bug#318150: linker cannot find -lXinerama_pic

[Marcin Owsiany]

Package: libxosd-dev
Severity: grave

It seems that with the new Xorg in sid, Xinerama_pic.a got lost
somewhere. It doesn't seem to be neither in xlibs-static-pic nor in
libxinerama* packages. As a consequence, linker does not work with what
xosd-cofig --libs produces, rendering the package unusable.

Marcin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#314937: invalid execve() usage

[Marcin Owsiany]

Package: jsvc
Version: 1.0-5
Severity: grave

As revealed by strace, jsvc tries to reexec itself without using full
path. This causes the package to be unusable.

execve("/usr/bin/jsvc", ["jsvc", "-home", "/usr/lib/j2sdk1.5-sun", 
"-Dcatalina.home=/opt/jakarta-tom"..., "-outfil e", 
"/opt/jakarta-tomcat/logs/catalin"..., "-errfile", "&1", "-pidfile", 
"/opt/jakarta-tomcat/temp/tomcat."..., "- cp", 
"/opt/kodo-jdo:/opt/kodo-jdo/lib/"..., "org.apache.catalina.startup.Boot"...], 
[/* 42 vars */]) = 0
uname({sys="Linux", node="melina11", ...}) = 0
brk(0)  = 0x805
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7fe9000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=50925, ...}) = 0
old_mmap(NULL, 50925, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fdc000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/tls/libdl.so.2", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\32"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9872, ...}) = 0
old_mmap(NULL, 8632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7fd9000
old_mmap(0xb7fdb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x2000) = 0xb7fdb000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7fd8000
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7ea3000
old_mmap(0xb7fcd000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x129000) = 0xb7fcd000
old_mmap(0xb7fd6000, 7308, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd6000
close(3)= 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fd8880, limit:1048575, 
seg_32bit:1, contents:0, read_exec_onl y:0, limit_in_pages:1, 
seg_not_present:0, useable:1}) = 0
munmap(0xb7fdc000, 50925)   = 0
brk(0)  = 0x805
brk(0x8071000)  = 0x8071000
brk(0)  = 0x8071000
stat64("/usr/lib/j2sdk1.5-sun", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/lib/j2sdk1.5-sun/jre/lib/jvm.cfg", 0xbfffdd9c) = -1 ENOENT (No 
such file or directory)
stat64("/usr/lib/j2sdk1.5-sun/lib/jvm.cfg", 0xbfffdd9c) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/j2sdk1.5-sun/jre/lib/i386/classic/libjvm.so", 0xbfffdd9c) = -1 
ENOENT (No such file or directory)
stat64("/usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so", 
{st_mode=S_IFREG|0644, st_size=4260981, ...}) = 0
execve("jsvc", ["jsvc.exec", "-home", "/usr/lib/j2sdk1.5-sun", 
"-Dcatalina.home=/opt/jakarta-tom"..., "-outfile", 
"/opt/jakarta-tomcat/logs/catalin"..., "-errfile", "&1", "-pidfile", 
"/opt/jakarta-tomcat/temp/tomcat."..., "-cp",  
"/opt/kodo-jdo:/opt/kodo-jdo/lib/"..., "org.apache.catalina.startup.Boot"...], 
[/* 43 vars */]) = -1 ENOENT (No s uch file or directory)
write(2, "jsvc error: ", 12jsvc error: )= 12
write(2, "Cannot execute JSVC executor pro"..., 36Cannot execute JSVC executor 
process) = 36
write(2, "\n", 1
)   = 1

This can be worked around by "ln -s /usr/bin/jsvc ."

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

Versions of packages jsvc depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libcommons-daemon-java  1.0-5Java API to launch java applicatio

jsvc recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#305751: keepalived: does not work with current sarge kernel

[Marcin Owsiany]

Package: keepalived
Version: 1.1.11-1
Severity: grave
Justification: renders package unusable

After installaton on a sarge system, it produces the following messages, and
does not set up ipvs rules.

Apr 21 17:09:13 kallisto Keepalived_healthcheckers: Registering Kernel netlink 
command channel
Apr 21 17:09:13 kallisto Keepalived_healthcheckers: Configuration is using : 
12310 Bytes
Apr 21 17:09:13 kallisto Keepalived_vrrp: Configuration is using : 31890 Bytes
Apr 21 17:09:13 kallisto Keepalived: Starting VRRP child process, pid=26583
Apr 21 17:09:13 kallisto kernel: IPVS: set_ctl: len 44 < 92
Apr 21 17:09:13 kallisto Keepalived_healthcheckers: IPVS: Module is wrong 
version
Apr 21 17:09:13 kallisto kernel: IPVS: set_ctl: len 68 < 92
Apr 21 17:09:13 kallisto kernel: IPVS: set_ctl: len 68 < 92
Apr 21 17:09:13 kallisto Keepalived_healthcheckers: IPVS: Module is wrong 
version
Apr 21 17:09:13 kallisto Keepalived_healthcheckers: IPVS: Module is wrong 
version

After modifying it to use 2.4.27 kernel-headers and rebuilding, it works.
However neither the description, nor the documentation says anything about
required kernel.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages keepalived depends on:
ii  ipvsadm 1.24+1.21-1  Linux Virtual Server support progr
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libpopt01.7-5lib for parsing cmdline parameters
ii  libssl0.9.7 0.9.7e-2 SSL shared libraries

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]