Bug#1057541: [ncurses-base] nload and possibly more, broken when launched over ssh (old issue reappears)

[Roman Mamedov]

Hello,

Downgrading to ncurses-base 6.2 (along with libncurses6 and libtinfo6) from
bullseye, solves it.

-- 
With respect,
Roman

Bug#1057539: [nload] Broken display after upgrading to bookworm

[Roman Mamedov]

Package: nload
Version: 0.7.4-1+b2
Severity: normal

Hello,

After upgrading my Debian version from bullseye to bookworm, I see that the
display became broken in 'nload'. It works fine for the first 6 updates, but
after that the numbers sections starts drifting towards the left, together
with the displayed bar graph. 

Since there has been no version update of 'nload' between the distro
versions, I guess these's some compatibility issue with the newer ncurses or
such.

Could you check on your end? Thanks

-- 
With respect,
Roman

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

On Fri, 14 Jul 2023 00:33:25 +0500
Roman Mamedov  wrote:

> There isn't really an image per board, but at least a clever system of
> concatenating a board-specific bootloader and a board-agnostic rest of the
> image. That looks reasonable enough, and I suppose building the current
> 12 bootloaders is automated. Maybe add all 42 to that automation for now?

Or actually, that was 42 just for Allwinner, and much much more if you include
other vendors. So adding them all to the regular build might not be as
feasible after all. I remember now, that's why I proposed building them all
not daily, but at least once per month.

-- 
With respect,
Roman

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

Hello,

On Thu, 13 Jul 2023 21:27:09 +0200
Emanuele Rocca  wrote:

> On 2023-07-01 04:18, Roman Mamedov wrote:
> > There are 42 DTBs shipped with the installer for Allwinner alone:
> > https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/
> > 
> > But for the bootloader aka firmware aka u-boot:
> > https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
> > it is an extremely weird and arbitrary list of 12 random boards. For 
> > instance
> > supporting "Orange Pi Zero Plus2" of all things specifically, not even just
> > "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on).
> 
> The choice of 12 boards does indeed look a little puzzling. Having no
> historical background on this, I can try and guess that they were added
> on a case-by-case basis every time someone needed to boot the installer
> on their system. Out of interest: do you have a board that's not among
> the lucky 12? :-)

Yes, as a weird coincidence with my initial message, I have an Orange Pi Prime
and Orange Pi Win. :)

> > So despite having all the other DTBs, the system is not installable on those
> > boards. Unless the user is sent to find and compile their own u-boot, but if
> > so, what is the purpose of randomly providing it for 12 random niche boards 
> > to
> > begin with, might as well make everyone do that.
> > 
> > Instead, I suggest a better solution: maybe not even daily, but at least 
> > once
> > per month, could you build a bootloader part for ALL the supported boards, 
> > and
> > not just a handful of them.
> 
> In an ideal world we would have just one single image that works on all
> systems! That's one of the ideas behind the Arm SystemReady
> certification program at least: making sure that the board can boot a
> regular, unmodified distro ISO without any additional blobs.
> 
> We don't live in such a world unfortunately, at least not yet and not
> for all boards. I'm not sure we should have one different image for each
> DTB honestly. I'd rather go for having no custom images at all, but a
> very simple procedure to build your own image for your board. Maybe in
> the form of documentation, or a script, or both.

There isn't really an image per board, but at least a clever system of
concatenating a board-specific bootloader and a board-agnostic rest of the
image. That looks reasonable enough, and I suppose building the current
12 bootloaders is automated. Maybe add all 42 to that automation for now?

-- 
With respect,
Roman

Bug#1040608: [solid-pop3d] Hardcoded connection ratelimit, "per source limit exceeded"

[Roman Mamedov]

Package: solid-pop3d
Version: 0.15-31
Severity: normal

Hello,

If the user connects too often to the POP3 server, solid-pop3d will eventually
refuse connections with a log message that "per source limit exceeded".

This is really weird and inconvenient. There is no word in man spop3d.conf
about such limit being present or how to configure or disable it.

In my case this is a trusted network and users, and they must be allowed to
connect as often as they like.

-- 
With respect,
Roman

Bug#1040010: [debian-installer] Please support more arm64 boards

[Roman Mamedov]

Package: debian-installer
Severity: normal

Hello,

There are 42 DTBs shipped with the installer for Allwinner alone:
https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/

But for the bootloader aka firmware aka u-boot:
https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/
it is an extremely weird and arbitrary list of 12 random boards. For instance
supporting "Orange Pi Zero Plus2" of all things specifically, not even just
"Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on).

So despite having all the other DTBs, the system is not installable on those
boards. Unless the user is sent to find and compile their own u-boot, but if
so, what is the purpose of randomly providing it for 12 random niche boards to
begin with, might as well make everyone do that.

Instead, I suggest a better solution: maybe not even daily, but at least once
per month, could you build a bootloader part for ALL the supported boards, and
not just a handful of them. Thanks!

-- 
With respect,
Roman

Bug#1019211: [html2text] Eats 6+GB RAM (or crashes if it can't) on a certain HTML file

[Roman Mamedov]

Package: html2text
Version: 1.3.2a-28
Severity: normal

Hello,

On a 512 MB of RAM machine with Bullseye:

  # html2text -utf8 < page.html 
  html2text: error: Cannot allocate memory
  Aborted

Trying the same on a 16 GB of RAM machine which runs Buster and the earlier
html2text version 1.3.2a-24, the program consumed 6 GB of RAM within a few
seconds of execution, after which I Ctrl+C'd it.

page.html is attached, but I am not sure if attachment comes through to the
BTS, I will follow up if it doesn't.

-- 
With respect,
Roman
Title: Ôîðìóëà-1 (2022) [ñòð. 1] :: Ñïîðò :: RuTracker.org















Ê ñòðàíèöå...


















Ãëàâíàÿ


Òðåêåð


Ïîèñê


Ãðóïïû


FAQ


Tor


VPN


Ïðàâèëà























Ðåãèñòðàöèÿ
 · 
Âõîä









SSL




Çàáûëè èìÿ èëè ïàðîëü?
















Ôîðìóëà-1 (2022)

Ñòðàíèöû :  1, 2, 3, 4, 5, 6, 7  Ñëåä.





 Ñïîðò
» Ñïîðòèâíûå òóðíèðû, ôèëüìû è ïåðåäà÷è
» Ôîðìóëà-1 (2022)



















Òåìû
Òîððåíò
Îòâ.
Ïîñë. ñîîáùåíèå


Ïðàâèëà







[×ÈÒÀÒÜ ÂÑÅÌ!] ÏÐÀÂÈËÀ ÎÁÙÅÍÈß Â ÏÎÄÐÀÇÄÅËÅ è ÏÐÀÂÈËÀ ÎÔÎÐÌËÅÍÈß ÐÀÇÄÀ×È


Çëîáíûé Ñàí÷åç






0



2017-03-07 10:34

Çëîáíûé Ñàí÷åç 




Âàæíîå







Ôëóäèëêà (Îñòîðîæíî, ìîãóò áûòü ðåçóëüòàòû)


IlVarsh
 [ 1 .. 22, 23 ] 





689



2022-09-04 20:12

KorDen32 









ãîðÿ÷àÿ Îáúÿâëåíèå. F1 2022 íà RuTracker


TomBeckett






0



2022-05-27 17:29

TomBeckett 









Íîâûé ìîäåðàòîð â ðàçäåëå Ôîðìóëà 1 - Stanst


Striker






0



2019-05-22 18:19

Striker 









Êîíêóðñ ïðîãíîçîâ


minjka






0



2019-03-11 10:05

minjka 




Îáúÿâëåíèÿ







√· Ìàêëàðåí / McLaren (Ðîäæåð Äîíàëüäñîí / Roger Donaldson) [2017, Íîâàÿ Çåëàíäèÿ, äîêóìåíòàëüíûé, äðàìà, áèîãðàôèÿ, ñïîðò, BDRip 1080p] MVO (Ìàò÷ ÒÂ) + Original Eng + Sub Eng


Neon_project





11 | 0


6.67 GB 




1


689



2022-07-17 12:58

SunMetal 









√· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 1 / Ñåðèè: 1-10 èç 10 / Netflix [2019, Ôîðìóëà 1, WEB-DL/1080p/25fps, MKV/H.264, RU/EN]


Dron ZX
 [ 1, 2 ] 




51 | 5


17.99 GB 




37


12,540



2022-06-22 17:15

DIMETRIUS_ 









*· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 4 / Ñåðèè: 1-10 èç 10 [2022, Ôîðìóëà 1, WEB-DL 1080p, RU, EN]


Êyle





49 | 6


21.34 GB 




13


6,473



2022-04-12 13:12

meskill 









*· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 4 [11.03.2022, Ôîðìóëà 1, WEB-DL, 1080p, h264, RU/EN]


d22t





9 | 0


18.19 GB 




19


779



2022-03-16 19:22

btharabth12 









T· [ Îïðîñ ] Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 4 [11.03.2022, Ôîðìóëà 1, WEB-DLRip, 1080p, h265, RU/EN]


d22t
 [ 1, 2 ] 




11 | 0


6.7 GB 




43


3,974



2022-03-14 21:16

d22t 









√· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 3 / Ñåðèè: 1-10 èç 10 [2021, Ôîðìóëà 1, WEB-DL 1080p, RU, EN]


Êyle
 [ 1, 2, 3 ] 




43 | 5


19.84 GB 




62


12,757



2022-01-15 16:14

TomBeckett 









*· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 4 [11.03.2022, Ôîðìóëà 1, WEB-DL, 1080p, 50 fps, h265, RU/EN]


d22t





9 | 2


23.41 GB 




14


1,407



2022-06-19 08:52

6milky6way6 









√· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 2 / Ñåðèè: 1-10 èç 10 [2020, Ôîðìóëà 1, WEB-DLRip/720p/25fps, MKV/H.264, RU, EN]


Striker





10 | 3


10.75 GB 




26


8,654



2022-03-18 22:23

äèìà-2 









√· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive. Netflix [2019, Ôîðìóëà 1, WEBRip/720p, MKV/H.264, EN]


PlayMaker1704
 [ 1, 2, 3 ] 




11 | 1


11.41 GB 




88


13,758



2022-03-08 15:04

eronex 









√· Remembering Sir Frank Williams. Sky Sports F1 HD [2013, 2019, 2021, Ôîðìóëà 1, ΙPTV/1080p/25fps, MKV/H.264, EN]


Ales





3 | 1


4.95 GB 




1


206



2021-12-03 23:22

Òîð÷åáàí 









√· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 2 / Ñåðèè: 1-10 èç 10 [2020, Ôîðìóëà 1, WEB-DL 1080p, RU,EN]


Êyle
 [ 1, 2 ] 




43 | 1


22.92 GB 




59


13,769



2022-03-24 11:57

TomBeckett 









√· Ôîðìóëà 1: Ãîíÿòü, ÷òîáû âûæèâàòü / Formula 1: Drive to Survive / Ñåçîí: 3 / Ñåðèè: 1-10 èç 10 [2021, Âåëèêîáðèòàíèÿ, Ôîðìóëà 1, WEB-DL 2160p, HDR, Dolby Vision, RU, EN] [Hybrid]


arxivariys





8 | 0


48.09 GB 




9


1,215



2022-05-27 07:25

Coma White 









√· Remembering Senna 25 Years On. Sky Sports F1 HD [2019, Ôîðìóëà 1, ΙPTV/1080p/25fps, MKV/H.264, EN]


Ales





3 | 1


3.07 GB 




5


608



2022-05-29 18:35

LoadMasta 




Èíñòðóêöèè







ãîðÿ÷àÿ *· Ôîðìóëà 1. Ñåçîí 2022. Ýòàï 15. Ãðàí-ïðè Íèäåðëàíäîâ. Ïðàêòèêè. Êâàëèôèêàöèÿ. Ãîíêà. F1TV [02-04.09.2022, Ôîðìóëà 1, WEB-DL/720p/50fps, MKV/H.264, RUS/UKR/ENG/INT]


KorDen32





20 | 125


12.68 GB 




15


1,059



2022-09-05 00:28

TomBeckett 









ãîðÿ÷àÿ *· Ôîðìóëà 1. Ñåçîí 2022. Ýòàï 15. Ãðàí-ïðè Íèäåðëàíäîâ. Ïðàêòèêè. Êâàëèôèêàöèÿ. Ãîíêà. F1TV [02-04.09.2022, 

Bug#1015831: [hddtemp] Please keep hddtemp in Debian

[Roman Mamedov]

Package: hddtemp
Severity: wishlist

Hello,

I have been surprised to see the changelog entry about the planned removal of
hddtemp. I would like to leave a couple of comments to that.

>  hddtemp has been dead upstream for many years and is therefore in a minimal
>  maintenance mode. It will be shipped in the Debian Bullseye release, but
>  will not be present in the Debian Bookworm release.

Could it be a case of a program that is basically _done_, i.e. it works, keeps
working, and doesn't need any changes or new features, other than "minimal
maintenance" in the first place?

Or could you give some examples of issues that arise and go unsolved because
of "dead" upstream? Seeing from next to no bugreports in Debian, doesn't seem
that there are many.

>  Nowadays the 'drivetemp' kernel module is a better alternative. It uses the
>  Linux Hardware Monitoring kernel API (hwmon), so the temperature is returned
>  the same way and using the same tools as other sensors.

Does not seem to be the case. Of course running "sensors" then returns:

> drivetemp-scsi-4-0
> Adapter: SCSI adapter
> temp1:+32.0°C  (low  =  +0.0°C, high = +60.0°C)
>(crit low = -40.0°C, crit = +65.0°C)
>(lowest = +28.0°C, highest = +42.0°C)

And what I wanted to know was the temperature of /dev/sda.

There is no "sensors /dev/sda" obviously, and not obvious for the user how to
easily convert sda to scsi-X-Y. Calling *this* the better alternative seems
extremely premature.

At least some wrapper should be introduced (or maybe there's already one?)
that would offer the exact command-line interface as hddtemp, but then
retrieve the temperature in "the better way" under the hood (if there's really
such a pressing need...)

Not to mention it would return 24 of these paragraphs when called
(interrupting all the drives to fetch temperature?), assuming e.g. 24 drives,
even if I wanted the temperature of just one.

>  Loading this module is as easy as creating a file in the /etc/modules-load.d
>  directory:
>
>echo drivetemp > /etc/modules-load.d/drivetemp.conf

Loading it might be easy, but as one proverb says, "only if you're not
interested in the results"...

-- 
With respect,
Roman

Bug#1015209: [rsyslog] No initscript anymore, not functional without systemd?

[Roman Mamedov]

On Sun, 17 Jul 2022 21:19:19 +0100
Mark Hindley  wrote:

> Of course rsyslog does still work without systemd. The initscript was removed
> and is now found in the orphan-sysvinit-scripts package.

Great to know, never heard of that package before.

But even though rsyslog as a program does still work without systemd, the
rsyslog as a package arguably doesn't, since installing it into a system
doesn't provide it with the logging functionality anymore, due to the daemon
not being automatically started on each boot-up. And it is not clear to a
user how to fix that.

As such I would then suggest considering:

  "Depends: systemd | orphan-sysvinit-scripts"

Thanks

-- 
With respect,
Roman

Bug#1015209: [rsyslog] No initscript anymore, not functional without systemd?

[Roman Mamedov]

On Sun, 17 Jul 2022 19:50:52 +0200
Michael Biebl  wrote:

> > I just found that on one of my upgraded Bullseye machines I do not have 
> > system
> > logs anymore, nor rsyslog running at all.
> > 
> > Trying to start it, I find that there's no /etc/init.d/rsyslog. I see there 
> > is
> > an rsyslog.service file, but these machines do not run systemd.
> > 
> > The problematic version is 8.2206.0-1~bpo11+1 from bullseye-backports. 
> > Another
> > machine still uses the bullseye version 8.2102.0-2+deb11u1 and it all works
> > fine on that one.
> > 
> > How to use the new version without systemd? Or what is the suggested
> > non-systemd alternative?
> > 
> 
> non-systemd systems are no longer supported.
> Please migrate.

Hello,

In that case could you please update the dependencies or conflicts of the new
package version, to indicate that it is now only functional with systemd. 

Loudly complaining at upgrade-time, or preventing upgrade, is certainly much
better than quietly leaving people's systems broken without logging. Nobody
will notice there aren't any logs, until they need something *from* the logs.

Maybe something like "Depends: systemd", or "Conflicts: sysvinit-core"?

Thanks!

-- 
With respect,
Roman

Bug#1015209: [rsyslog] No initscript anymore, not functional without systemd?

[Roman Mamedov]

Package: rsyslog
Version: 8.2206.0-1~bpo11
Severity: normal

Hello,

I just found that on one of my upgraded Bullseye machines I do not have system
logs anymore, nor rsyslog running at all.

Trying to start it, I find that there's no /etc/init.d/rsyslog. I see there is
an rsyslog.service file, but these machines do not run systemd.

The problematic version is 8.2206.0-1~bpo11+1 from bullseye-backports. Another
machine still uses the bullseye version 8.2102.0-2+deb11u1 and it all works
fine on that one.

How to use the new version without systemd? Or what is the suggested
non-systemd alternative?

Thanks!

-- 
With respect,
Roman

Bug#1014659: logrotate: error: state file /var/lib/logrotate/status is world-readable

[Roman Mamedov]

Hello,

Here is the permission layout after the "error" message has been issued. I did
not check what it was before. I'm not sure if this means I will not get
another "error" tomorrow. On another host, I did "chmod o-rx" on the logrotate
directory, thinking maybe it wants that. Not sure yet if that helped either.

# ls -la /var/lib/logrotate/
total 12
drwxr-xr-x  2 root root 4096 Jul 10 06:32 .
drwxr-xr-x 29 root root 4096 Jun 22 13:44 ..
-rw-r-  1 root root  782 Jul 10 06:32 status

-- 
With respect,
Roman

Bug#1005018: [procps] snice: does not work anymore in 3.3.15

[Roman Mamedov]

Hello,

I guess this is a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903540

But Buster currently has the broken version. In that case please consider this
as a request to update the version there.

-- 
With respect,
Roman

Bug#1005018: [procps] snice: does not work anymore in 3.3.15

[Roman Mamedov]

Package: procps
Version: 2:3.3.15-2
Severity: normal

snice has no effect on process priority anymore, neither when invoked with the 
process
name, nor with a user name.

With version 3.3.9 it worked fine. I did not test versions in-between.

Running a process of:

  sleep 3600

And doing:

  snice +20 sleep

Results in the following strace snippet for 3.3.15:

  openat(AT_FDCWD, "/proc/7135/stat", O_RDONLY) = 4
  fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
  read(4, "7135 (sleep) S 6836 7135 6836 34"..., 128) = 128
  close(4)

Downgrading to 3.3.9 and repeating:

  openat(AT_FDCWD, "/proc/7135/stat", O_RDONLY) = 4
  fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
  read(4, "7135 (sleep) S 6836 7135 6836 34"..., 128) = 128
  openat(AT_FDCWD, "/proc/tty/drivers", O_RDONLY) = 5
  read(5, "/dev/tty /dev/tty   "..., ) = 465
  close(5)= 0
  stat("/dev/pts2", 0x7fff202e0460)   = -1 ENOENT (No such file or 
directory)
  stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  readlink("/proc/7135/fd/2", "/dev/pts/2", 127) = 10
  stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x2), ...}) = 0
  setpriority(PRIO_PROCESS, 7135, 20) = 0
  close(4)

-- 
With respect,
Roman

Bug#1002007: [glusterfs-server] Does not include an init script

[Roman Mamedov]

Package: glusterfs-server
Version: 9.2-1~bpo10+1
Severity: normal

From package description: "This package installs init scripts and configuration
files to turn GlusterFS into a fully fledged file server."

But it does not actually include any init scripts:

  ls /etc/init.d/*gluster*
  ls: cannot access '/etc/init.d/*gluster*': No such file or directory

Only includes systemd service files, but I do not use systemd.

As far as I'm aware it was never made mandatory in Debian.

As is, it is unclear how to actually start the server.

-- 
With respect,
Roman

Bug#993679: [init-system-helpers] Upgrading from Jessie to Bullseye fails

[Roman Mamedov]

Package: init-system-helpers
Version: 1.60
Severity: normal

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  libcwidget3 libsigc++-2.0-0c2a
The following NEW packages will be installed:
  bsdextrautils dirmngr gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client 
gpg-wks-server gpgconf gpgsm libapparmor1 libapt-pkg6.0
  libassuan0 libboost-iostreams1.74.0 libbpf0 libcap2-bin libcwidget4 
libdns-export1110 libelf1 libfastjson4 libip4tc2 libip6tc2
  libisc-export1105 libksba8 liblognorm5 liblz4-1 libmd0 libmnl0 libncurses6 
libncursesw6 libnetfilter-conntrack3 libnftnl11 libnpth0
  libprocps8 libreadline8 libseccomp2 libsigc++-2.0-0v5 libtinfo6 libuchardet0 
libutempter0 libxapian30 libxtables12 libxxhash0 libzstd1
  ncal pinentry-curses
The following packages will be upgraded:
  apt apt-utils aptitude aptitude-common base-files base-passwd bash 
bsdmainutils bsdutils ca-certificates coreutils cpio cpufrequtils
  cron dash dbus debian-archive-keyring deborphan debsums dialog diffutils dpkg 
eatmydata ethtool findutils gettext-base gnupg gpgv grep
  groff-base gzip hostapd hostname ifupdown info init init-system-helpers 
initscripts insserv install-info iperf iproute2 iptables
  iputils-ping iputils-tracepath isc-dhcp-client isc-dhcp-common kmod 
krb5-locales less libacl1 libattr1 libbsd0 libcap2 libcpufreq0
  libdbus-1-3 libdebconfclient0 libdpkg-perl libeatmydata1 libedit2 libestr0 
libexpat1 libgnutls-openssl27 libidn11 libiw30 libkmod2
  liblzo2-2 libmount1 libncurses5 libncursesw5 libnewt0.52 libnfnetlink0 
libnl-3-200 libnl-genl-3-200 libnl-route-3-200 libopts25 libpcre3
  libpcsclite1 libpipeline1 libpopt0 libsasl2-modules libslang2 libsmartcols1 
libsqlite3-0 libss2 libstdc++6 libsystemd0 libtimedate-perl
  libtinfo5 libudev1 libusb-0.1-4 libusb-1.0-0 libustr-1.0-1 libuuid1 libwrap0 
libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6
  libxmuu1 login logrotate lzop man-db manpages mawk mount mtr-tiny nano 
ncurses-base ncurses-bin ncurses-term net-tools netbase
  netcat-traditional ntp ntpdate openssl procps readline-common rsyslog screen 
sed smartmontools ssh startpar sysv-rc sysvinit-core
  sysvinit-utils tasksel tasksel-data tcpd time traceroute tzdata ucf udev 
usbutils util-linux vlan wget whiptail wireless-tools
  wpasupplicant xauth xz-utils
148 upgraded, 46 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B/57.8 MB of archives.
After this operation, 44.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 17942 files and directories currently installed.)
Preparing to unpack .../init-system-helpers_1.60_all.deb ...
Unpacking init-system-helpers (1.60) over (1.22) ...
dpkg: error processing archive 
/var/cache/apt/archives/init-system-helpers_1.60_all.deb (--unpack):
 trying to overwrite '/usr/sbin/invoke-rc.d', which is also in package sysv-rc 
2.88dsf-59
Errors were encountered while processing:
 /var/cache/apt/archives/init-system-helpers_1.60_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
With respect,
Roman

Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution

[Roman Mamedov]

On Tue, 10 Aug 2021 20:20:23 +0200
Paul Gevers  wrote:

> I learned yesterday that people that use APT pinning or
> APT::Default-Release may be missing out -updates if they pin to buster
> only. See the latest entry to the release notes [1, last paragraph] to
> cover the issue for bullseye-security. I'm obviously not sure if that
> happened here, but if the issue is the same on ci.d.n infrastructure, it
> would explain the failure there (the logs from yesterday there mention
> "Setting up shim-signed:arm64 (1.36~1+deb10u1+15.4-5~deb10u1)".

I have regained access to some cloud instances with that setup today.

Created them from an older backup, and I see that I do have in my apt.conf:

  APT::Default-Release "buster";
  APT::Install-Recommends "false";

And:

# apt-cache policy shim-signed
shim-signed:
  Installed: 1.33+15+1533136590.3beb971-7
  Candidate: 1.36~1+deb10u1+15.4-5~deb10u1
  Version table:
 1.36~1+deb10u2+15.4-5~deb10u1 500
500 https://deb.debian.org/debian buster-updates/main arm64 Packages
 1.36~1+deb10u1+15.4-5~deb10u1 990
990 https://deb.debian.org/debian buster/main arm64 Packages
 *** 1.33+15+1533136590.3beb971-7 100
100 /var/lib/dpkg/status

Indeed the "Candidate" to be installed is what is supposedly the broken
version.

After changing the config line to

  APT::Default-Release "/^buster(|-security|-updates)$/";

the updated version is selected correctly.

It does not feel great to now have a version selection with such dire
consequences to rely on "the undocumented feature of APT".

(So I just chose to "aptitude hold" the old one for now instead).

> [1]
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

It appears they meant "-updates" there, instead of typoed "-upgrades" in their
suggested config line, unless I'm missing something.

-- 
With respect,
Roman

Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution

[Roman Mamedov]

On Sun, 25 Jul 2021 12:43:48 +0100
Steve McIntyre  wrote:

> Which provider is using secure boot on arm64 at this point? I've not
> heard of any. Can you share details of package versions etc. for that
> please?

It is the Oracle Cloud.

Actually I am not certain they use secure boot, or that the lack of signature
is the issue. According to serial console, the issue was a fatal crash in the
UEFI boot loader (TianoCore). So I assumed it could be because it did not find
the signature it was expecting to validate.

Unfortunately I did not save the crash messages and cannot reproduce it for
now, as I am not longer able to start my instances due to "Out of host
capacity" at the provider.

As for the package versions, I was using the vanilla Debian Buster.

-- 
With respect,
Roman

Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution

[Roman Mamedov]

On Sun, 25 Jul 2021 20:19:55 +0500
Roman Mamedov  wrote:

> As for the package versions, I was using the vanilla Debian Buster.

Here is the log of the upgrade after which it no longer booted up:

Hit:1 https://deb.debian.org/debian-security buster/updates InRelease
Hit:2 https://deb.debian.org/debian buster InRelease
Get:3 https://deb.debian.org/debian buster-backports InRelease [46.7 kB]
Get:4 https://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Get:5 https://deb.debian.org/debian buster-backports/main arm64 
Packages.diff/Index [27.8 kB]
Get:6 https://deb.debian.org/debian buster-backports/main arm64 Packages 
2021-07-25-0801.36.pdiff [950 B]
Get:6 https://deb.debian.org/debian buster-backports/main arm64 Packages 
2021-07-25-0801.36.pdiff [950 B]
Fetched 127 kB in 1s (147 kB/s)
Reading package lists... Done
The following NEW packages will be installed:
  linux-image-5.10.0-0.bpo.7-arm64{a} 
The following packages will be upgraded:
  base-files isc-dhcp-client isc-dhcp-common klibc-utils libgcrypt20 
libgnutls30 libgssapi-krb5-2 libhogweed4 libk5crypto3 libklibc 
  libkrb5-3 libkrb5support0 libnettle6 libsystemd0 libudev1 linux-image-arm64 
shim-helpers-arm64-signed shim-signed 
  shim-signed-common shim-unsigned udev 
The following packages are RECOMMENDED but will NOT be installed:
  krb5-locales 
21 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.2 MB of archives. After unpacking 256 MB will be used.
Do you want to continue? [Y/n/?] y
Get: 1 https://deb.debian.org/debian buster/main arm64 base-files arm64 
10.3+deb10u10 [69.9 kB]
Get: 2 https://deb.debian.org/debian-security buster/updates/main arm64 
libsystemd0 arm64 241-7~deb10u8 [314 kB]
Get: 3 https://deb.debian.org/debian-security buster/updates/main arm64 udev 
arm64 241-7~deb10u8 [1244 kB]
Get: 4 https://deb.debian.org/debian-security buster/updates/main arm64 
libudev1 arm64 241-7~deb10u8 [146 kB]
Get: 5 https://deb.debian.org/debian buster/main arm64 libgcrypt20 arm64 
1.8.4-5+deb10u1 [488 kB]
Get: 6 https://deb.debian.org/debian-security buster/updates/main arm64 
libnettle6 arm64 3.4.1-1+deb10u1 [225 kB]
Get: 7 https://deb.debian.org/debian-security buster/updates/main arm64 
libhogweed4 arm64 3.4.1-1+deb10u1 [138 kB]
Get: 8 https://deb.debian.org/debian buster/main arm64 libgnutls30 arm64 
3.6.7-4+deb10u7 [1062 kB]
Get: 9 https://deb.debian.org/debian buster/main arm64 isc-dhcp-client arm64 
4.4.1-2+deb10u1 [328 kB]
Get: 10 https://deb.debian.org/debian buster/main arm64 isc-dhcp-common arm64 
4.4.1-2+deb10u1 [144 kB]
Get: 11 https://deb.debian.org/debian-security buster/updates/main arm64 
libgssapi-krb5-2 arm64 1.17-3+deb10u2 [150 kB]
Get: 12 https://deb.debian.org/debian-security buster/updates/main arm64 
libkrb5-3 arm64 1.17-3+deb10u2 [351 kB]
Get: 13 https://deb.debian.org/debian-security buster/updates/main arm64 
libkrb5support0 arm64 1.17-3+deb10u2 [64.9 kB]
Get: 14 https://deb.debian.org/debian-security buster/updates/main arm64 
libk5crypto3 arm64 1.17-3+deb10u2 [123 kB]
Get: 15 https://deb.debian.org/debian buster/main arm64 klibc-utils arm64 
2.0.6-1+deb10u1 [99.3 kB]
Get: 16 https://deb.debian.org/debian buster/main arm64 libklibc arm64 
2.0.6-1+deb10u1 [57.1 kB]
Get: 17 https://deb.debian.org/debian buster-backports/main arm64 
linux-image-5.10.0-0.bpo.7-arm64 arm64 5.10.40-1~bpo10+1 [45.4 MB]
Get: 18 https://deb.debian.org/debian buster-backports/main arm64 
linux-image-arm64 arm64 5.10.40-1~bpo10+1 [1464 B]
Get: 19 https://deb.debian.org/debian buster/main arm64 shim-unsigned arm64 
15.4-5~deb10u1 [342 kB]
Get: 20 https://deb.debian.org/debian buster/main arm64 
shim-helpers-arm64-signed arm64 1+15.4+5~deb10u1 [234 kB]
Get: 21 https://deb.debian.org/debian buster/main arm64 shim-signed arm64 
1.36~1+deb10u1+15.4-5~deb10u1 [247 kB]
Get: 22 https://deb.debian.org/debian buster/main arm64 shim-signed-common all 
1.36~1+deb10u1+15.4-5~deb10u1 [13.3 kB]
Fetched 51.2 MB in 1s (47.3 MB/s)
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: news for 
Preconfiguring packages ...
(Reading database ... 26475 files and directories currently installed.)
Preparing to unpack .../base-files_10.3+deb10u10_arm64.deb ...
Unpacking base-files (10.3+deb10u10) over (10.3+deb10u9) ...
Setting up base-files (10.3+deb10u10) ...
Installing new version of config file /etc/debian_version ...
(Reading database ... 26475 files and directories currently installed.)
Preparing to unpack .../libsystemd0_241-7~deb10u8_arm64.deb ...
Unpacking libsystemd0:arm64 (241-7~deb10u8) over (241-7~deb10u7) ...
Setting up libsystemd0:arm64 (241-7~deb10u8) ...
(Reading database ... 26475 files and directories currently installed.)
Preparing to unpack .../udev_241-7~deb10u8_arm64.deb ...
Unpacking udev (241-7~deb10u8) over (241-7~deb10u7) ...
Preparing to unpack .../libudev1_241-7~deb10u8_arm64.deb ...
Unpacking libudev1:arm64 (241-7~deb10u8) over (241-7~deb1

Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution

[Roman Mamedov]

Package: shim-signed
Severity: grave

Starting from 1.34~1+deb10u1 and its corresponding "***WARNING***", now the
arm64 shim "is no longer signed".

As a result, after a mundane package upgrade and a reboot, all of my remote
arm64 machines do not boot anymore. I was not aware that the cloud provider
actually uses this "secure boot", else I'd pay more attention to that
"WARNING".

In any case, relying on the user reading upgrade notes, and then to scramble
rolling back the upgrade and holding the affected package ASAP, else the
system is bricked, is not a responsible package policy.

I would humbly suggest that you kept the latest signed version frozen at least
in "buster" with no further updates, until the signing issue is resolved. Or
as of now, release another update with the signed version in place.

P.S. just noticed 1.36~1+deb10u2 tried to do something about the boot breakage
- evidently that did not help.

-- 
With respect,
Roman

Bug#576959: jnettop: No IPv6 on PPP interface

[Roman Mamedov]

Hello,

Just wanted to confirm that this remains an issue even though more than 10
years have passed since the initial bug report.

Thanks

-- 
With respect,
Roman

Bug#966471: [qbittorrent-nox] Version kept from Stretch fails to launch after Buster upgrade

[Roman Mamedov]

Package: qbittorrent-nox
Version: 3.3.7-3
Severity: normal

I kept version 3.3.7-3 of the package from Stretch via 'aptitude hold' and
upgraded the rest of the system to Buster. Now it does not launch with the
error:

/usr/bin/qbittorrent-nox: symbol lookup error: /usr/bin/qbittorrent-nox:
undefined symbol: 
_ZN10libtorrent7session5startEiRKNS_13settings_packEPN5boost4asio10io_serviceE

All dependencies on the system are satisfied.

Downgrading libtorrent-rasterbar9 from 1.1.11-2 to 1.1.1-1+b1 (and adding the
libboost 1.62 packages that it requires) makes it work again.

It seems like the dependencies are poorly specified for this package.

-- 
With respect,
Roman

Bug#877667: firmware-realtek: please add RTL8812 firmware (rtl8812aefw.bin & rtl8812aefw_wowlan.bin)

[Roman Mamedov]

Hello,

Unfortunately 3 years later this is still not added, the device still works
much worse without it, and it is still required to obtain the firmware
separately to get the proper performance.

The repository at the URL referenced got deleted since then, but can still
accessed via:
https://github.com/lwfinger/rtlwifi_new/tree/5406ea7f6f2ae1cc0da9e6f65a94c58d7d563b23/firmware/rtlwifi

-- 
With respect,
Roman

Bug#944444: [aggregate] Please add IPv6 support

[Roman Mamedov]

Package: aggregate
Version: 1.6-7+b1
Severity: normal

$ echo 2001:db8::/32 | aggregate
aggregate: maximum prefix length permitted will be 32
aggregate: [line 1] can't parse prefix '2001:db8::'; ignoring line
aggregate: no prefixes supplied

It is bizarre that with Debian's goal of full IPv6 support, in 2019 you still
have stuff like this in the repos.

-- 
With respect,
Roman

Bug#944445: [iprange] Doesn't support IPv6, and doesn't mention that it doesn't

[Roman Mamedov]

Package: iprange
Version: 1.0.3+ds-1
Severity: normal

Fails in a bad way when trying to use IPv6:

$ echo 2001:db8::/32 | iprange 
iprange: Ignoring text after hostname '2001' on line 1: ':db8::/32
'
0.0.7.209

Please add v6 support or a better error message than this.

Also, the current description claims that "This tool is capable of managing
sets of IPs." and so on. Well, nope, it's only capable of managing sets of 
IPv4s.
I hoped it would do IPv6, but installing and trying it turned out to be just a
waste of time.

-- 
With respect,
Roman

Bug#941328: [curl] A lot of new puzzling and seemingly useless output in "verbose"

[Roman Mamedov]

Package: curl
Version: 7.64.0-4
Severity: normal

Up until now "curl -v" was reasonably useful for debugging a connection issue
or for posting to others to demonstrate issues with their website.

But currently its signal to noise ration has plummeted -- what is all this
"Expire in" garbage, and is it really useful for anything?

Seems more like leftovers of debug output useful only to developers of curl
itself, not for any real-world usage.

Stretch version 7.52.1-5+deb9u9 not affected.

# curl -Iv4 ya.ru
* Expire in 0 ms for 6 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 3 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 3 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 5 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 5 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 6 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 6 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 10 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 10 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 11 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 11 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 14 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 14 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 15 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 15 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
*   Trying 87.250.250.242...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55cb96de7d00)
* Connected to ya.ru (87.250.250.242) port 80 (#0)
> HEAD / HTTP/1.1
> Host: ya.ru
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 302 Found
HTTP/1.1 302 Found
< Location: https://ya.ru/
Location: 

Bug#905247: nload broken when executed via SSH

[Roman Mamedov]

On Mon, 8 Jul 2019 12:26:08 -0300
Marcio Souza  wrote:

> Hello,
> 
> I need the more info. I tried to reproduce the bug, but I don't see
> this problem. I run nload over ssh from Debian 10(Gnome desktop) to
> other Debian 10 without problem. I've changed severity to important
> because this problem does not make the package unusable.[1]
> 
> Please give me more information. What's your desktop system, what's
> the server system?

Server system is Debian 10, desktop is Debian 9.9, running Xfce4 Terminal
0.4.8 inside a vnc4server session. I don't think any of this is related,
expect maybe the SSH "from Debian 9 to 10" part.

One hunch that I had, is which locale do you use? Mine is:

LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

Both on server and client.

-- 
With respect,
Roman

Bug#905247: And still not fixed for Buster release

[Roman Mamedov]

Severity: grave

Downgrading ncurses back to Debian Stretch versions fixes the issue for me.

Namely, to
libncurses5_6.0+20161126-1+deb9u2_amd64.deb
libtinfo5_6.0+20161126-1+deb9u2_amd64.deb
ncurses-base_6.0+20161126-1+deb9u2_all.deb

-- 
With respect,
Roman

Bug#873086: ifupdown script disables IPv6 on parent of VLAN interface

[Roman Mamedov]

Hello,

Actually, both 1.6-2 and 1.5-16 still disable IPv6 on the parent interface for
me, in a config like this:

iface br-test inet static
  address 192.168.9.101
  netmask 255.255.255.0
  bridge-ports eth1.1008

After "ifup br-test", /proc/sys/net/ipv6/conf/eth1/disable_ipv6 is set to 1.

-- 
With respect,
Roman

Bug#873086: ifupdown script disables IPv6 on parent of VLAN interface

[Roman Mamedov]

Hello,

I just hit this bug as well. From what I see this has been fixed in 1.5-16,
but Stretch currently contains 1.5-13+deb9u1. And 1.5-16 is not available in
any archive. The Buster version is 1.6-2. Is it possible to push the fixed
version to Stretch?

Thanks

-- 
With respect,
Roman

Bug#891324: radvd: Claims ::/64 prefix is invalid in the log

[Roman Mamedov]

Hello,

This is fixed upstream:
https://github.com/reubenhwk/radvd/commit/b37baa1137d0bd5b9cceb2e447550f1c0a105ac6

-- 
With respect,
Roman

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Roman Mamedov]

On Fri, 8 Feb 2019 10:42:06 +0100
Aurelien Jarno  wrote:

> Yes, that's normal that only LANG is set, as it's the one with less
> priority. That said there was clearly something setting LC_ALL to
> en.US-UTF-8 before, you might want to grep /etc for that. When only LANG
> is set, you should get and output like this one:

Thanks, turns out in my case the "culprit" was LC_ALL getting passed from the
ssh client each time, due to /etc/ssh/sshd_config:

  # Allow client to pass locale environment variables
  AcceptEnv LANG LC_*

-- 
With respect,
Roman

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Roman Mamedov]

On Fri, 8 Feb 2019 10:21:41 +0100
Aurelien Jarno  wrote:

> What is the content of /etc/default/locale? it looks like you have an
> additional entry than the LANG one set by dpkg-reconfigure locales.

"dpkg-reconfigure locales" only writes LANG=C.UTF-8 (or any other accordingly)
to that file. This results in the "locale" output that I posted above
(including after a relogin or reboot). There were no lines aside from that
in /etc/default/locale.

I was able to get the desired result only by manually adding a line with
"LC_ALL=C.UTF-8" to /etc/default/locale.

# locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=C.UTF-8

It is puzzling why this is required.

-- 
With respect,
Roman

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Roman Mamedov]

So for those of us (the entire world), who have been relying on this behavior:

> * en_US (.UTF-8) is used as the default English locale for all places that
>   don't have a specific variant (and often even then).  Generally, technical
>   users use English as a system locale

How do we roll-back what you have done here, and still get en_US.UTF-8 while
retaining the proper 24-hour time?

dpkg-reconfigure locales does not list "C.UTF-8" in the main "locales to
generate" list, but does offer it on the next screen as "Default locale for the
system environment". After selecting it, we get:

# locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

But still:

# date
Thu 07 Feb 2019 09:53:47 AM UTC

-- 
With respect,
Roman

Bug#912312: [iproute2] Space before subnets in "ip rule" output

[Roman Mamedov]

Package: iproute2
Version: 4.18.0-2~bpo9+1
Severity: normal

On 4.18.0-2~bpo9+1:

ip -6 rule

...
3500:   from all to 2a00:1450:: /32 lookup main 
3500:   from all to 2a02:6b8:: /32 lookup main 
3500:   from all to 2a02:2698:: /32 lookup main 
...

On 4.9.0-1+deb9u1:

...
3500:   from all to 2a00:1450::/32 lookup main
3500:   from all to 2a02:6b8::/32 lookup main 
3500:   from all to 2a02:2698::/32 lookup main 
...

Not all records are like that on the 4.18, for example there are some which do
not exhibit the problem:

...
100:from 66:113::/64 lookup main 
:   from 66::/16 lookup vpn
...

-- 
With respect,
Roman

Bug#904423: Great catch

[Roman Mamedov]

Thanks for this report!

And I here was wondering why my IRQBALANCE_ARGS doesn't work. This must be the
dumbest bug ever. And the fact that it's not fixed since months and is still
present in the current release, unfortunately shows the appalling state that
Debian is in currently.

-- 
With respect,
Roman

Bug#897933: libguestfs0 insane dependency hell

[Roman Mamedov]

Yep, stumbled upon this just now too, as trying to get just one simple utility
which happens to be packaged in "libguestfs-tools", suddenly wanted to install
a DHCP client and systemd on my machine. Folks, seriously? Moreover, stretch
was supposed to be usable without systemd, but here we have:

  dep: systemdsystem and service manager

  or sysvinit Package not available

How can you have package in stretch (option-)depend on a package not in it?
I'm not an expert on your packaging names, but I suppose the new name for that
one is sysvinit-core.

Too sad to see Debian at this level of quality, I guess there's really no
other option than to migrate to Devuan.

-- 
With respect,
Roman

Bug#889867: [claws-mail] selection jumps to the last item in a folder after Delete

[Roman Mamedov]

Package: claws-mail
Version: 3.14.1-3+b1
Severity: normal

When a folder has multiple messages, selecting any of them and pressing the
"Delete" key deletes the message and then jumps the selection cursor to the
very last message in that folder.

This is not observed with 3.11.1-3+deb8u1. In that version, after pressing the
Delete key the cursor remains logically in the same position, i.e. moves on to
message which was adjacent to the just-deleted one.

-- 
With respect,
Roman

Bug#876252: mhddfs segfaults seemingly randomly (not from updatedb like other bug)

[Roman Mamedov]

On Wed, 20 Sep 2017 01:16:08 -0700
Ben Gladstone  wrote:

> I'm just waiting to see if it crashes in the next week or so. Have you tried
> that patch yet?

As I have no crashes even without the patch, I can't provide any useful
testing. Perhaps I no longer hit that corner case which you still do. Let's
hope it fixes that for you.

-- 
With respect,
Roman

Bug#876252: mhddfs segfaults seemingly randomly (not from updatedb like other bug)

[Roman Mamedov]

On Wed, 20 Sep 2017 00:49:06 -0700
Ben Gladstone  wrote:

> I unfortunately haven't been able to identify a pattern, but every couple of 
> days mhddfs
> crashes, giving me the message "The transport endpoint is not connected." 
> when I try to access
> anything mounted by mhddfs. It's easy enough to fix, just "umount -l 
>  && mount "
> and it starts working again, but when it crashes it causes problems for any 
> programs currently
> accessing that directory.
> 
> When it crashes, this line appears in dmesg:
> 
> mhddfs[561]: segfault at 0 ip 559e3eae159c sp 7f2cded0da50 error 4 in 
> mhddfs[559e3eadc000+a000]
> 
> I researched this issue and found a number of people talking about it online 
> but I didn't find a bug
> report on the Debian bug tracker (I'm pretty sure it's not the same bug as 
> the segfault caused by updatedb).
> 
> I believe I've found someone who's patched it already though, here's
> his blog post about it: 
> http://nramkumar.org/tech/blog/2015/09/23/mhddfs-crash-with-ubuntu-14-04/. He 
> has posted the patch here: 
> https://github.com/ram-nat/mhddfs/commit/26d0f119eaa7e3ffaaf330bf29672e13471cb091.
> 
> I'm trying out his precompiled binary to see if it fixes the issue for me as 
> well, but it hasn't been
> long enough to know yet. Anyway, assuming it works, can we get this patch 
> merged into the main branch?

FWIW I had tons of segfaults with mhddfs in the past (usually when browsing
the mounted FS with Thunar file manager), then I've not used it for a period of
time, then went back to using it recently, and have zero segfaults whatsoever
now.

I don't know what could be the change helping with this, in any case my
versions are:

Kernel 4.9.41 (Self-compiled)
fuse   2.9.3-15+deb8u2
libc6:amd642.24-11+deb9u1
mhddfs 0.1.39+nmu1

One thing to check (some hunch), is any of your joined paths actually a symlink
itself?

-- 
With respect,
Roman

Bug#868043: [vnstat] Version 1.15 changes output units and removes rounding, with no way to configure?

[Roman Mamedov]

Package: vnstat
Version: 1.15-2
Severity: normal

Hello,

Upgrading from Jessie version 1.12 to Stretch version 1.15 changes the output
format of vnstat -h significantly. Now bandwidth values are in a different
unit and no longer rounded to integer. This not only looks worse by adding
extra useless noise to the visual representation, it also broke several scripts
for me which process this output in an automated monitoring and report system.

Previously:

 eth0 13:55 
  ^ t   
  | t  tt   
  |  rt rt rt rt rt rt  tt rt   
  |  rt rt rt rt rt rt rt rtrt rt rtrt rt rt
  |  rt rt rt rt rt rt rt rt rtrtrt rtrtrt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
 -+---> 
  |  14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13

 h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB) 
14   39693559   4220958222   32611864   3322218606   26443418   27074479
15   41173062   4414054823   27608905   2803791407   35113453   37291018
16   42858673   4944113900   30440238   3114062408   37476406   38917220
17   43008290   4612526001   28682376   2951775009   34960298   35353913
18   40935287   4304286302   30669009   3155507910   33981103   34487964
19   40458885   4363524003   31485532   3287089111   38165294   39693801
20   38586455   3993217704   26205215   2701091012   42433494   44623397
21   38848113   3953566905   34302997   3449298813   37786045   38771759

How this looks now in Stretch: 

 eth0 13:54 
  ^t
  |  t  t  t
  |  t rt rt  t 
  |  rt rt rt rt rt  trt t rt   
  |  rt rt rt rt rt rt rt   rt rt rt rt rt rt  t  t 
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt  t   
  |  rt rt rt rt rt rt rt rt rt   t rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt
 -+---> 
  |  14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13

 h  rx (MiB)   tx (MiB)  h  rx (MiB)   tx (MiB)  h  rx (MiB)   tx (MiB) 
14   20337.62   21865.6422   15158.41   15718.2506   18301.87   19016.12
15   22071.46   26758.50239935.18   10364.0407   18955.16   20125.97
16   23127.88   27981.0100   11037.72   11407.7208   20806.30   21897.03
17   23204.97   28679.6301   10175.09   10653.7509   17064.68   17680.97
18   20348.89   23030.5802   11361.97   12010.0110   16837.38   18391.96
19   19259.43   21582.4803   17226.79   17677.1611   15989.15   16455.30
20   17598.63   18322.1204   19500.40   19911.9212   14180.97   14585.10
21   16021.17   16941.8805   21891.91   22777.5213   12445.74   13851.71

How to restore the previous output format?

There are RateUnit and UnitMode config variables, both are useless to help with
this issue.

Thanks

-- 
With respect,
Roman

Bug#863516: [ntpdate] Returns success exit code on errors

[Roman Mamedov]

Package: ntpdate
Version: 1:4.2.6.p5+dfsg-7+deb8u2
Severity: normal

On (some?) errors ntpdate exits with zero (success) exit code:

# ntpdate 2.pool.ntp.org && echo OK || echo Fail
21 Oct 22:34:55 ntpdate[2729]: Can't adjust the time of day: Invalid argument
OK

--- System information. ---
Architecture: armhf
Kernel:   3.4.104-r0-d20-rm2+

-- 
With respect,
Roman

Bug#814339: nghttp2: missing build-dependency on python-sphinxcontrib.rubydomain

[Roman Mamedov]

Hello,

I just hit the same snag that the original report is describing, and had to
spend some time digging around to figure out what's wrong. Would it really
hurt to just add the single missing build-depends line as the OP is proposing?

Alternatively, yes, please backport the 1.17 version into jessie-backports,
it's really so much different and more feature-complete than 0.64 which is
currently there.

Thanks

-- 
With respect,
Roman

Bug#656862: Bug#827031: xvnc4viewer: crashes with stack smashing on startup

[Roman Mamedov]

On Tue, 14 Jun 2016 14:21:47 +0200
Ola Lundqvist  wrote:

> It was not Torsten who wrote the patch.

> Just FYI.

Apologies for assuming that he did. Guess I jumped to replying due to facing
this attitude too often, that things must be ultra-hardened and uber-secure,
without any concern if it's actually usable (SELinux comes to mind).

Thanks!

-- 
With respect,
Roman


pgp5kkA5XK7p0.pgp
Description: OpenPGP digital signature

Bug#656862: Bug#827031: xvnc4viewer: crashes with stack smashing on startup

[Roman Mamedov]

On Tue, 14 Jun 2016 14:02:42 +0200 (CEST)
Thorsten Glaser  wrote:

> > Thanks a lot for your report. It happen to be the harden-build flag
> > correction that caused this. I have reverted that now and will upload
> 
> Erm… how about you fix the bug instead? The hardened build just makes
> the system reliably crash instead of unreliably use Undefined Behaviour,
> corrupt data, etc.
> 
> > a corrected package shortly.
> 
> You mean a security-wise broken package that may corrupt user data?

The package worked just fine for years for thousands of people before your
patch, without any reports of data corruption or undefined behavior. Now,
adding the patch renders it unusable by "making it reliably crash", it is
arguably up to YOU as the patch author to check for AND correct any arising
regressions -- not ordering other people around to correct your mess.

-- 
With respect,
Roman


pgpBDLGEHaEXk.pgp
Description: OpenPGP digital signature

Bug#818474: [mini-httpd] 1.21 lost HTTPS support

[Roman Mamedov]

Package: mini-httpd
Version: 1.21-1
Severity: normal


Hello,

I am trying out the version from Stretch, and find that it does not support
HTTPS anymore. Comparison:

mini-httpd 1.19-9.3:

# mini-httpd  --help
usage:  mini-httpd [-C configfile] [-D] [-S] [-E certfile] [-Y cipher] [-p
port] [-d dir] [-dd data_dir] [-c cgipat] [-u user] [-h hostname] [-r] [-v]
[-l logfile] [-i pidfile] [-T charset] [-P P3P] [-M maxage]


mini-httpd 1.21-1:

# mini_httpd --help
usage:  mini_httpd [-C configfile] [-D] [-p port] [-d dir] [-dd data_dir] [-c
cgipat] [-u user] [-h hostname] [-r] [-v] [-l logfile] [-i pidfile] [-T
charset] [-P P3P] [-M maxage]

Can you please re-enable the HTTPS support. Thanks

-- 
With respect,
Roman


pgpQP8DPblfox.pgp
Description: OpenPGP digital signature

Bug#815523: [rsync] New "copying unsafe symlink" warning after upgrade to 3.1.1

[Roman Mamedov]

Package: rsync
Version: 3.1.1-3
Severity: normal

Hello,

After upgrade from 3.0.9 (Wheezy) to 3.1.1 (Jessie) my scripts started
producing many "copying unsafe symlink" warnings;

it is correct that all of those are unsafe symlinks, but I do use the explicit
--copy-unsafe-links flag, and copying them is exactly what I want rsync to do.
Why does it now spam the log about this?

After some searching I found this old bug:
https://bugzilla.samba.org/show_bug.cgi?id=3147
Back then the conclusion was that copying unsafe symlinks when
"--copy-unsafe-links" is specified is just the normal operation of the
program, and that no log message should be printed about it.

So what happened here? How do I return the behavior back to how it was?

-- 
With respect,
Roman


pgp0xn_gb_Prg.pgp
Description: OpenPGP digital signature

Bug#652100: Fixed in 4.3-11+b1

[Roman Mamedov]

fixed 652100 version 4.3-11+b1
thanks

For the record, as of 4.3-11+b1 the problem does not occur anymore.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#812592: Requires systemd on Jessie for no particular reason

[Roman Mamedov]

Package: k3b
Version: 2.0.2-8

Hello,

I find that on Jessie the k3b package requires running a systemd-based OS.

  k3b depends on: udisks2
  udisks2 depends on: libpam-systemd
  libpam-systemd depends on: systemd

This is even more baffling when you consider that the Jessie version of k3b is
2.0.2-8, whereas the Wheezy version is 2.0.2-6. So there are probably no
actual systemd-using changes in the program to mandate its requirement.

Running non-systemd init systems such as 'sysvinit' and 'upstart' is also
a supported configuration in Debian Jessie. But their users can't currently
install k3b without breaking their systems.

Can you please reconsider to update the dependencies so that systemd is not
required to use k3b.

Thanks!

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#765479: squid3: Seem to ignore size restriction set by cache_dir (overflow partition)

[Roman Mamedov]

Hello,

I can confirm this behavior. It occurs simply during normal usage.

I am using:

  cache_dir aufs /var/spool/squid3 1 16 32

However the cache dir on one host was way over that, close to 30 GB. Luckily
that partition still had a considerable amount of free space.



-- 
With respect,
Roman


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

Bug#777195: [squid3] tcp_outgoing_address ignored

[Roman Mamedov]

Package: squid3
Version: 3.4.8-5~bpo70+1
Severity: normal

Hello,

On some occasions I was using the directive tcp_outgoing_address 0.0.0.0 to
force Squid on a dual-stack host to be IPv4-only.

This works fine on 3.1.20-2.2+deb7u2 currently in Wheezy.

However, this directive is ignored on the 3.4 version from backports.

Even setting tcp_outgoing_address [actual IPv4 address of the host] does not
help, Squid still makes outgoing connections from IPv6 as well.

-- 
With respect,
Roman


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

Bug#767317: [gajim] Please upgrade Recommends to Depends on python-pyasn1, critical for SSL/TLS to work

[Roman Mamedov]

Package: gajim
Version: 0.15.1-4.1
Severity: normal

Hello,

Without the python-pyasn1 package Gajim cannot properly verify validity of
server SSL certificates, it will always fail with a misleading error message of
The certificate does not cover this domain. [1]

What's worse, this does not give any indication that it's not a problem with
the certificate, but that python-pyasn1 merely needs to be installed.

Encryption support is a critical piece of functionality in a modern IM client,
it can't be something that's optional, or needs additional components to be
manually installed. (And for example I run my system with
APT::Install-Recommends false, with this is the first noticeable breakage
caused by this that I can remember in years.)

Given that python-pyasn1 is a 51KB package which itself does not have any
non-trivial dependencies, I think upgrading this to Depends should be a
no-brainer.

[1] https://bugs.launchpad.net/ubuntu/+source/gajim/+bug/1379059


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14.22-rm1+

Debian Release: 7.7
  990 stable  security.debian.org 
  990 stable  deb.x.romanrm.net 
  100 wheezy-backports deb.x.romanrm.net 

--- Package information. ---
Depends (Version) | Installed
=-+-==
python  (= 2.6.6-7~) | 2.7.3-4+deb7u1
python-gtk2   (= 2.22.0) | 2.24.0-3+b1
dnsutils  | 1:9.8.4.dfsg.P1-6+nmu2+deb7u2


Recommends   (Version) | Installed
==-+-===
dbus   | 1.6.8-1+deb7u4
python-dbus| 1.1.1-1
notification-daemon| 0.7.6-1
python-openssl   (= 0.12) | 0.13-2+deb7u1
python-crypto  | 2.6-4+deb7u3
python-pyasn1  | 


Suggests(Version) | Installed
=-+-===
python-gconf  | 2.28.1+dfsg-1
python-gnome2 | 
nautilus-sendto   | 
avahi-daemon  | 
python-avahi  | 
network-manager   | 
libgtkspell0  | 
aspell-en | 7.1-0-1
python-gnomekeyring   | 
gnome-keyring | 
python-kerberos  (= 1.1) | 
texlive-latex-base| 
dvipng| 
python-farstream  | 
gstreamer0.10-plugins-ugly| 0.10.19-2+b2
python-pycurl | 
python-gupnp-igd  | 







-- 
With respect,
Roman


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

Bug#766509: vnc4server: apt-get autoremove --purge does not remove .vnc/* config files

[Roman Mamedov]

On Thu, 23 Oct 2014 18:02:21 +0100
James Anslow jam...@ddxor.com wrote:

 Removing vnc4server via apt-get with the --purge flag leaves config files in 
 the users .vnc/ directory.
 
 As creating these config files is a part of normal operation of the 
 vnc4server application, and since the --purge flag is supposed to (also) 
 remove configuration files, this seems like inappropriate behaviour.

No package *ever* removes any config files in user directories on --purge.
The --purge flag only affects system-wide configs in /etc/.
This is the normal behavior.

-- 
With respect,
Roman


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

Bug#765453: [wide-dhcpv6-client] Does not have a cooldown period on retries

[Roman Mamedov]

Package: wide-dhcpv6-client
Severity: normal

In some situations it will retry multiple times per second.
One such case caused the upstream to block the client as a source of UDP flood.
See the log attached.

Oct 15 07:37:55 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:37:55 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:37:55 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:37:55 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:37:55 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:37:55 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:37:55 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=125, retrans=127152
Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:37:58 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:37:58 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=124, retrans=116796
Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:37:58 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:37:58 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:37:58 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:37:58 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=125, retrans=123816
Oct 15 07:38:01 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:38:01 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:38:01 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:38:01 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:38:01 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:38:01 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:38:01 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=125, retrans=108048
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:38:02 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:38:02 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=125, retrans=109668
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:38:02 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:38:02 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=124, retrans=131100
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:38:02 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:38:02 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:38:02 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:38:02 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=125, retrans=112320
Oct 15 07:38:03 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:38:03 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:38:03 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:38:03 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:38:03 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 07:38:03 luka dhcp6c[2093]: client6_send: send solicit to ff02::1:2%eth0
Oct 15 07:38:03 luka dhcp6c[2093]: dhcp6_reset_timer: reset a timer on eth0, 
state=SOLICIT, timeo=125, retrans=117516
Oct 15 07:38:04 luka dhcp6c[2093]: copy_option: set client ID (len 10)
Oct 15 07:38:04 luka dhcp6c[2093]: copyout_option: set identity association
Oct 15 07:38:04 luka dhcp6c[2093]: copy_option: set rapid commit (len 0)
Oct 15 07:38:04 luka dhcp6c[2093]: copy_option: set elapsed time (len 2)
Oct 15 07:38:04 luka dhcp6c[2093]: copyout_option: set IA_PD
Oct 15 

Bug#763722: [openbsd-inetd] Thinks no services are enabled, if all of the enabled services are specified by their IPv6 listen address

[Roman Mamedov]

Package: openbsd-inetd
Version: 0.20091229-2
Severity: normal

Hello,

There's this function in /etc/init.d/openbsd-inetd:

checknoservices () {
if ! grep -q ^[[:alnum:]/] /etc/inetd.conf; then
log_action_msg Not starting internet superserver: no services enabled
exit 0
fi
}

It will mistakenly think that no services are enabled, in case when all
enabled services have been specified by their IPv6 listen address, like so:
/etc/inetd.conf:

[2001:db8::1]:81 stream tcp6 nowait proxy /bin/nc6 nc6 -w 20 host1.example.com 
81
[2001:db8::2]:81 stream tcp6 nowait proxy /bin/nc6 nc6 -w 20 host2.example.com 
81
[2001:db8::3]:81 stream tcp6 nowait proxy /bin/nc6 nc6 -w 20 host3.example.com 
81

As you can see all of the non-commented lines start with [, which the grep
in initscript currently will not properly match.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14.18-rm1+

Debian Release: 7.6
  990 stable  www.emdebian.org 
  990 stable  approx.home.romanrm.net 
  100 wheezy-backports approx.home.romanrm.net 

--- Package information. ---
Depends(Version) | Installed
-+-
libc6   (= 2.4) | 2.13-38+deb7u4
libwrap0 (= 7.6-4~) | 7.6.q-24
lsb-base (= 3.2-13) | 4.1+Debian8+deb7u1
update-inetd | 4.43
tcpd | 7.6.q-24


Package's Recommends field is empty.

Package's Suggests field is empty.






-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#592552: [knutclient] An UPS Load of 0 (zero) causes the Load graph to show up garbled

[Roman Mamedov]

On Sat, 13 Sep 2014 19:04:48 +1000
Dmitry Smirnov only...@debian.org wrote:

 Dear Roman,
 
 It's been a while and since this bug was reported knutclient was removed 
 then re-introduced back to Debian. I don't see the problem in current version 
 1.0.5 so I believe it was fixed. Could you please confirm so we could close 
 this bug? Thanks.
 
Hello,

Sorry I no longer have the conditions necessary to reproduce it. Feel free to
close, next time me or someone else hits this, it can be reopened or
re-reported.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#761056: [sitecopy] Can't seem to handle FTP filenames longer than 79 characters

[Roman Mamedov]

Package: sitecopy
Version: 1:0.16.6-4
Severity: normal

Hello,

If I try to upload a site where a file named longer than 79 characters exists,
it will upload the file giving it an incorrect name it on the server: cutting
the name short at 79th character.

On subsequent fetch+upload cycles it will delete the incorrectly named file,
then proceed to upload it again, once more under the same cut-off name. This
will repeat indefinitely.

For testing I manually created a file on the FTP server with a name longer
than 79 characters. After this sitecopy can no longer successfully fetch such
website, with the error 550 Can't check for file existence.

Looks like somewhere the FTP filenames are incorrectly chopped to 79 (perhaps
80, with the trailing #0) bytes.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14.14-rm1+

Debian Release: 7.6
  990 stable  www.emdebian.org 
  990 stable  approx.home.romanrm.net 
  100 wheezy-backports approx.home.romanrm.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
libc6(= 2.3.4) | 2.13-38+deb7u4
libneon27-gnutls| 0.29.6-3


Package's Recommends field is empty.

Package's Suggests field is empty.






-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#761056: (update) Can't use long pathnames with some(?) FTP servers

[Roman Mamedov]

retitle 761056 Can't use long pathnames with some(?) FTP servers
thanks

Hello,

Sorry, after some more testing the limitation appears to be of a different
nature: a total length of path+filename maximum of 198 characters, that can
be passed in one command.

For testing I have now created a directory on the FTP server, named as (without
spaces):
012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x

And inside it, a file named:
01234567890012345678900123456789001234567890012345678900123456789001234567890z

Trying to get the modification time of that file in one go:

ftp cd /
250 OK. Current directory is /
ftp quote MDTM 
/012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x/01234567890012345678900123456789001234567890012345678900123456789001234567890z
550 Can't check for file existence

This is the same error that sitecopy is hitting.

But, if I first 'cd' into the long-named directory and then issue MDTM with a
shorter argument (just the filename), it works:

ftp cd 
012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x
250 OK. Current directory
is 
/012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890012345678900123456789001234567890x
ftp quote MDTM 
01234567890012345678900123456789001234567890012345678900123456789001234567890z
213 20140910132003

Unfortunately sitecopy seems to issue its file operations with absolute
pathnames, which end up being too long for (this particular?) server to
handle, and that's what is causing the problem.

I wonder if this is just a limitation of my provider's particular FTP server.

Regardless, it'd be nice to have a mode where sitecopy would 'cd' into
directories one by one, to allow for a longer total pathname than the FTP
server has decided to allow fitting into one command argument.

ftp usecwd option seems to be very close, but it does not affect how MDTM is
issued during fetch (and for the above example to work, it must be issued only
on files in the current working directory too).

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#757927: [qemu-kvm] TRIM (discard=unmap) broken in 2.1

[Roman Mamedov]

On Wed, 13 Aug 2014 10:05:51 +0400
Michael Tokarev m...@tls.msk.ru wrote:

 BTW, I found a system here with an SSD which supports discard, and tried my
 guests against it -- everything works fine when I use sata/ahci, but it breaks
 indeed when using the default IDE interface.

Hello,

Thanks for working on this! Sorry for not being able to test an updated
version sooner.

Something to note, you do not need any TRIM-capable hardware such as SSD on the
host to take advantage of TRIM passthrough. Just place the RAW format VM disk
image on any filesystem which supports sparse files (e.g. Ext4 or Btrfs), and
when the guest system issues a TRIM, when using discard=unmap the VM image
file will be re-sparsifyed on the host filesystem, deallocating all the
TRIMed areas from disk storage, in effect it will take much less space on disk
than before:
http://s.lowendshare.com/7/1407910491.666.2014-07-16T130602Z-trim.png

I was only successful in using this with the virtual IDE interface disks on
Qemu/KVM 2.0, the virtio mode does not seem to support TRIM; did not try with
sata/ahci.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#757927: [qemu-kvm] TRIM (discard=unmap) broken in 2.1

[Roman Mamedov]

Package: qemu-kvm
Version: 2.1+dfsg-2~bpo70+2
Severity: normal

Hello,

I was able to successfully use the passthrough TRIM support with an IDE
interface virtual disk in Qemu-KVM version 2.0.

However after upgrading to 2.1 and restarting my VM, TRIM now fails in it with
messages like those quoted below (dmesg from the guest). There are no messages
in dmesg related to that on the host.

I run two VMs, and the other has not been restarted yet (it's running with the
old 2.0 binaries), and there TRIM works without issue. So it clearly seems to
be due to some change in 2.1.

[   63.096106] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   63.097698] ata1.00: BMDMA stat 0x4
[   63.098470] ata1.00: failed command: DATA SET MANAGEMENT
[   63.099245] ata1.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 0 dma 512 
out
[   63.099245]  res 41/04:01:00:00:00/04:01:00:00:00/a0 Emask 0x1 
(device error)
[   63.100894] ata1.00: status: { DRDY ERR }
[   63.101698] ata1.00: error: { ABRT }
[   63.102465] ata1.00: device reported invalid CHS sector 0
[   63.102471] sd 0:0:0:0: [sda]  
[   63.102473] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   63.102474] sd 0:0:0:0: [sda]  
[   63.102475] Sense Key : Aborted Command [current] [descriptor]
[   63.102477] Descriptor sense data with sense descriptors (in hex):
[   63.102478] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 
[   63.102482] 00 00 00 00 
[   63.102484] sd 0:0:0:0: [sda]  
[   63.102485] Add. Sense: No additional sense information
[   63.102486] sd 0:0:0:0: [sda] CDB: 
[   63.102487] Write same(16): 93 08 00 00 00 00 00 84 37 60 00 00 00 18 00 00
[   63.102492] end_request: I/O error, dev sda, sector 8664928
[   63.103438] EXT4-fs (sda1): discard request in group:33 block:1516 count:3 
failed with -5
[   63.256058] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   63.256897] ata1.00: BMDMA stat 0x4
[   63.257697] ata1.00: failed command: DATA SET MANAGEMENT
[   63.258479] ata1.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 0 dma 512 
out
[   63.258479]  res 41/04:01:00:00:00/04:01:00:00:00/a0 Emask 0x1 
(device error)
[   63.260126] ata1.00: status: { DRDY ERR }
[   63.260954] ata1.00: error: { ABRT }
[   63.261731] ata1.00: device reported invalid CHS sector 0
[   63.261737] sd 0:0:0:0: [sda]  
[   63.261738] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   63.261739] sd 0:0:0:0: [sda]  
[   63.261740] Sense Key : Aborted Command [current] [descriptor]
[   63.261742] Descriptor sense data with sense descriptors (in hex):
[   63.261743] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 
[   63.261747] 00 00 00 00 
[   63.261749] sd 0:0:0:0: [sda]  
[   63.261750] Add. Sense: No additional sense information
[   63.261751] sd 0:0:0:0: [sda] CDB: 
[   63.261752] Write same(16): 93 08 00 00 00 00 00 93 c8 08 00 00 00 38 00 00
[   63.261757] end_request: I/O error, dev sda, sector 9685000
[   63.262756] EXT4-fs (sda1): discard request in group:36 block:30721 count:7 
failed with -5
[   66.328099] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   66.328991] ata1.00: BMDMA stat 0x4
[   66.329811] ata1.00: failed command: DATA SET MANAGEMENT
[   66.330659] ata1.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 0 dma 512 
out
[   66.330659]  res 41/04:01:00:00:00/04:01:00:00:00/a0 Emask 0x1 
(device error)
[   66.332307] ata1.00: status: { DRDY ERR }
[   66.333122] ata1.00: error: { ABRT }
[   66.333918] ata1.00: device reported invalid CHS sector 0
[   66.333923] sd 0:0:0:0: [sda]  
[   66.333925] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   66.333926] sd 0:0:0:0: [sda]  
[   66.333927] Sense Key : Aborted Command [current] [descriptor]
[   66.333929] Descriptor sense data with sense descriptors (in hex):
[   66.333930] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 
[   66.333934] 00 00 00 00 
[   66.333936] sd 0:0:0:0: [sda]  
[   66.333937] Add. Sense: No additional sense information
[   66.333938] sd 0:0:0:0: [sda] CDB: 
[   66.333939] Write same(16): 93 08 00 00 00 00 00 84 48 60 00 00 00 08 00 00
[   66.333944] end_request: I/O error, dev sda, sector 8669280
[   66.335084] EXT4-fs (sda1): discard request in group:33 block:2060 count:1 
failed with -5
[   67.332057] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   67.332929] ata1.00: BMDMA stat 0x4
[   67.333745] ata1.00: failed command: DATA SET MANAGEMENT
[   67.334574] ata1.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 0 dma 512 
out
[   67.334574]  res 41/04:01:00:00:00/04:01:00:00:00/a0 Emask 0x1 
(device error)
[   67.336264] ata1.00: status: { DRDY ERR }
[   67.337114] ata1.00: error: { ABRT }
[   67.337936] ata1.00: device reported invalid CHS sector 0
[   67.337942] sd 0:0:0:0: [sda]  
[   67.337943] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   67.337945] sd 0:0:0:0: [sda]  
[   67.337946] Sense Key : Aborted Command [current] [descriptor]
[   67.337948] 

Bug#757927: [qemu-kvm] TRIM (discard=unmap) broken in 2.1

[Roman Mamedov]

Hello,

Just confirmed that downgrading the package qemu-system-x86 from version
2.1+dfsg-2~bpo70+2 to 2.0.0+dfsg-4~bpo70+1 and restarting the affected VM
fixes this, TRIM starts working again without issue.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#750945: approx does not work via ipv6 link local address

[Roman Mamedov]

On Sun, 08 Jun 2014 20:43:40 +0200
Tim Schumacher t...@datenknoten.me wrote:

 I'm setting up some vm foo and wanted to use approx to cache downloads.
 
 I put the following in my sources.lst on the client:
 
 deb http://[fe80::fc54:ff:fe1a:1922%eth0]:/debian/packages/ jessie main 
 contrib non-free
 
 I think the %eth0 is required to specify the device.

Can you name any other client software which supports this in URLs? 

Wget, curl, browsers, ftp clients, media players - none do.

For that reason *no one* uses link-local addresses for HTTP.

Set yourself up some ULA range[1], and better yet, assing some DNS names so you
don't have to use bare IPs in URLs (which too, can be a complicated issue with
curl).

If you still want link-locals to work, in case of approx you likely need to
complain to curl, since that's what it uses under-the-hood for HTTP.

[1] https://en.wikipedia.org/wiki/Unique_local_address

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#728113: [smartmontools] Fails to run on a Wheezy/Jessie mixed system

[Roman Mamedov]

Package: smartmontools
Version: 6.2+svn3841-1
Severity: normal





$ sudo /etc/init.d/smartmontools start
[] Starting S.M.A.R.T. daemon: smartdInconsistency detected by ld.so: 
dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' 
failed!

$ sudo smartctl -a /dev/sda
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: 
Assertion `needed != ((void *)0)' failed!






All the dependencies seem to be satisfied. Maybe they are not stated
correctly/strictly enough?



--- System information. ---
Architecture: amd64
Kernel:   Linux 3.10.13-rm2+

Debian Release: 7.2
  990 testing www.emdebian.org 
  990 stable  approx.home.romanrm.net 
  500 testing approx.home.romanrm.net 
  100 wheezy-backports approx.home.romanrm.net 

--- Package information. ---
Depends(Version) | Installed
-+-=
libc6  (= 2.17) | 2.17-93
libcap-ng0   | 0.6.6-2
libgcc1 (= 1:4.1.1) | 1:4.7.2-5
libselinux1(= 1.32) | 2.1.9-5
libstdc++6(= 4.1.1) | 4.8.1-10
debianutils (= 2.2) | 4.3.2
lsb-base (= 3.2-14) | 4.1+Debian8+deb7u1


Recommends  (Version) | Installed
=-+-===
mailx | 
 OR mailutils | 


Suggests(Version) | Installed
=-+-===
gsmartcontrol | 
smart-notifier| 



--- Output from package bug script ---
Output of /usr/share/bug/smartmontools:



-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#622325: bus lock still a problem

[Roman Mamedov]

On Mon, 26 Aug 2013 11:06:52 -0400
Russ H chairman.fa...@gmail.com wrote:

 I compiled a vanilla 3.10.8 kernel on my DNS-323 arm box... still getting
 this bug:

Hello,

Did you do a full power-off of your device after running a previous unpatched
version on it? Because as I found out, booting a bugged kernel even once
locks-up the bus for good and merely rebooting the DNS-323 doesn't restore
access. Try doing a full power-off including disconnecting the power cord
before trying the new kernel.

(Of course the problem could be something else entirely).

 
 root@a110755:~# uname -r
 3.10.8-orion5x
 root@a110755:~# pwmconfig
 # pwmconfig revision 5857 (2010-08-22)
 This program will search your sensors for pulse width modulation (pwm)
 controls, and test each one to see if it controls a fan on
 your motherboard. Note that many motherboards do not have pwm
 circuitry installed, even if your sensor chip supports pwm.
 We will attempt to briefly stop each fan using the pwm controls.
 The program will attempt to restore each fan to full speed
 after testing. However, it is ** very important ** that you
 physically verify that the fans have been to full speed
 after the program has completed.
 Found the following devices:
hwmon0/device is g760a
 Found the following PWM controls:
hwmon0/device/pwm1
 [  382.279864] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
 [  384.279860] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
 [  386.279861] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
 [  388.279859] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
 Giving the fans some time to reach full speed...
 Found the following fan sensors:
 [  395.349854] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
 [  397.349861] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
 [  399.349853] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
hwmon0/device/fan1_input current speed: 0 ... skipping!
 There are no working fan sensors, all readings are 0.
 Make sure you have a 3-wire fan connected.
 You may also need to increase the fan divisors.
 See doc/fan-divisors for more information.


-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#705855: Fullscreen selected on title bar not reflected in pop-up menu

[Roman Mamedov]

On Sun, 21 Apr 2013 03:16:43 +
Mike deb...@good-with-numbers.com wrote:

 Package: xvnc4viewer
 Version: 4.1.1+X4.3.0-37.1
 Severity: minor
 
 Selecting Fullscreen from the title bar menu enables fullscreen mode.  
 But then pressing F8 to get the pop-up menu, no check mark is next to 
 Full screen.

These are two different fullscreen modes. One is provided by the VNC Viewer
internally, and the other is by your window manager. Their behaviors differ
a bit, too. For example if your VNC resolution is smaller than your monitor
resolution, the window manager fullscreen may not be available, whereas the
internal one will work, and will fill the unused parts of the screen with
black color.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#705855: Fullscreen selected on title bar not reflected in pop-up menu

[Roman Mamedov]

On Sun, 21 Apr 2013 19:43:51 +
Mike deb...@good-with-numbers.com wrote:

 why then does it come out of full-screen mode? if there really are two 
 different 
 full-screen modes?

Probably because disabling the built-in fullscreen also sends a window resize
command, which is a sign to the window manager to go out of fullscreen as well.

 This is with xfwm4.  BTW, it's not obvious to me how to take the window 
 out of the window manager's full-screen mode.

Try Alt+F11.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#705855: Fullscreen selected on title bar not reflected in pop-up menu

[Roman Mamedov]

On Sun, 21 Apr 2013 20:38:26 +
Mike deb...@good-with-numbers.com wrote:

 So, then, these two modes are irreconcilable? there's no standard API 
 for a window manager and its client to communicate their full-screen 
 intentions to the other?

- not every window manager provides an integrated fullscreen mode;

- Xfwm4 will for example refuse to make a 1280x1024 VNC window fullscreen on a
  1680x1050 monitor, whereas you can still freely use the Viewer's built-in
  fullscreen mode in such situation, having the unused area of the screen
  blacked-out.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#548897: unison: Please optimise from copy+delete to rename

[Roman Mamedov]

Hello,

Very disappointing to see this still not fixed even after 3 years.

Maybe there's a chance to at least change the copy to cp --reflink (so it
completes instantly on supporting filesystems)?

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#637386: IPv6

[Roman Mamedov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 9 Dec 2012 15:54:22 -0700
Brett Wuth w...@castrov.cuug.ab.ca wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi,
 
 This bug has cropped up on one of the systems I administer.  It
 appears to be the result of *all* client IPv6 addresses being
 incorrectly translated into the IPv4 address 0.0.0.0, and so lumped in
 together thus enabling a denial of service.
 
 The critical code appears to be in
 vnc4-4.1.1+X4.3.0/common/network/TcpSocket.cxx
 
 char* TcpSocket::getPeerAddress() {
   struct sockaddr_in  info;
   struct in_addraddr;
   VNC_SOCKLEN_T info_size = sizeof(info);
 
   getpeername(getFd(), (struct sockaddr *)info, info_size);
   memcpy(addr, info.sin_addr, sizeof(addr));
 
   char* name = inet_ntoa(addr);
   if (name) {
 return rfb::strDup(name);
   } else {
 return rfb::strDup();
   }
 }
 
 where inet_ntoa assumes an IPv4 address, so returns 0.0.0.0.
 
 This erroneous address is then matched with other IPv6 attempts in:
 
 vnc4-4.1.1+X4.3.0/common/rfb/VNCServerST.cxx
 
 void VNCServerST::addSocket(network::Socket* sock, bool outgoing)
 {
   // - Check the connection isn't black-marked
   // *** do this in getSecurity instead?
   CharArray address(sock-getPeerAddress());
   if (blHosts-isBlackmarked(address.buf)) {
 connectionsLog.error(blacklisted: %s, address.buf);
 try {
   SConnection::writeConnFailedFromScratch(Too many security failures,
   sock-outStream());
 
 Cheers,
 - -- 
 Brett Wuth  w...@castrov.cuug.ab.ca w...@acm.org
 Box 1251-U, Pincher Creek, Alberta T0K 1W0, CANADA  Tel:+1 403 627-2460
 OpenPGP FingerPrint=628F C9DA BDBC 2A0E 18F1  2F6A 3300 8422 BE6A 0E79
 What is the meaning of life?!  Yes.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/
 
 iEYEARECAAYFAlDFFpwACgkQ8qwj3joz1ZA/cwCfQftPtxUsS0aDUxdq3zQkOnmA
 GB0AnRXX1hG5L84LEfFSBEbal6bio3CM
 =YY/k
 -END PGP SIGNATURE-

First, please title the bug reports properly, a bug report titled IPv6 does
not tell much.

Second, if you are so knowledgeable in the nature of the problem, surely you
must have a verified patch to propose, that fixes it?

Finally, to clarify: there is no denial of service against VNC in general,
it's just that the rate limiting of incorrect connection attempts currently
applies to all IPv6 addresses that are trying to connect, rather than to
actual specific ones. And rate-limiting individual IPv6 addresses is kind of
pointless anyway -- until a proper subnet-matching support is implemented --
since an attacker could easily instantiate many millions of different unique
addresses even within their /64.

Of course one could argue that to do such rate-limiting in each app is a wrong
idea altogether, and this is actually the job of ip6tables.

- -- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlDFm8EACgkQTLKSvz+PZwgeGwCdELdiqUaf5Yjk8TfdMrrUwOZi
uUwAn1jHxkEjQbaowA2lLZN6bjkg+qTB
=9RZe
-END PGP SIGNATURE-

Bug#692521: vnc4server: Drag-and-drop doesn't work

[Roman Mamedov]

On Tue, 06 Nov 2012 19:44:19 -0800
Jon Foster j...@jfpossibilities.com wrote:

 Drag and drop function don't appear to work in programs running under
 vnc4server. Specifically dragging files around in rox-filer either within the
 same window or from window to window or window to pinboard fails to do
 anything. The file(s) fly back to where they came from. The mouse pointer
 never changes to show the action that should take place. I've seen other
 reports of this on the Internet going back to 2010, specifically in Ubuntu.
 
 Actually moving and resizing windows on screen works fine... although that
 doesn't classify as a drag-and-drop operation to me. I've had this problem
 under OpenBox and E16 window managers. The same program works fine under
 xserver-xorg.
 
 I did try rolling back to the Lenny version and had the same problem, which
 works fine when running on Lenny instead of Squeeze.

Hello,

From what I could understand this was due to a bug in some other package, not
in vnc4server. Please see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619413

Drag-and-drop in vnc4server works fine in the current Debian Wheezy.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#528992: mtr: No DNS resolution in trace, when only IPv6 transport used

[Roman Mamedov]

Hello,

There are now patches fixing this in https://bugs.launchpad.net/bugs/752583

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#594684: xserver-xorg-video-siliconmotion: siliconmotion driver segfaults on a Lemote YeeLoong

[Roman Mamedov]

 Bug opened on Xorg.

Problem is -- at Xorg, no one gives a damn.

Panayiotis Karabassis submitted it, and have not received any proper review or
even any sort of formal accepted/declined reply about the patch.

That was one year ago. So another year of hassle with three hour compiles of
Xorg for every end user with this problem.

OK, there might be very few users of this particular hardware. Out of them
maybe 2 or 3 people are Xorg developers. And they are newbie ones, at that. It
is very easy for Debian and Xorg maintainers to ignore the issue -- and we
can't do anything about it. Other than maybe paying cash -- hey everyone, how
about, I dunno, a Kickstarter campaign? to get the Debian MIPS Xorg patched to
operate on SiliconMotion? Then we could find one of these hard-working
maintainers and pay them to add that single line into that quilt file or a do
some git pull to apply the already prepared patch that solves an actual
problem. If that's the only way to get this done.

I do not have a good solution to resolving this bug, I just think no one
would've been harmed much, and people would be very thankful, if this would
simply included into Debian, and that should've been done a long time ago.

Free software sometimes works out so well.

-- 
With respect,
Roman



signature.asc
Description: PGP signature

Bug#684315: [thinkfan] Tries to write level 0 to sysfs, not just 0

[Roman Mamedov]

Package: thinkfan
Version: 0.8.0-1
Severity: grave

It looks like starting from version 0.8.0 this program no longer works at all.



# /usr/sbin/thinkfan -n

WARNING: Using safe but wasteful way of setting PWM value. Check README to know 
more.
WARNING: You're using simple temperature limits without correction values, and 
your fan will only start at 63 °C. This can be dangerous for your hard drive.

sleeptime=5, tmax=57, last_tmax=57, biased_tmax=57 - fan=level 0
setfan_sysfs: Error writing to /sys/class/hwmon/hwmon0/pwm1: Invalid argument
Cleaning up and resetting fan control.
#



It seems to attempt writing level 0 into /sys/class/hwmon/hwmon0/pwm1, which
of course fails, because only integer values are allowed there:

# echo level 0  /sys/class/hwmon/hwmon0/pwm1
-bash: echo: write error: Invalid argument

# echo 0  /sys/class/hwmon/hwmon0/pwm1
# 
(worked)

I am kind of amazed how this kind of error could possibly have been introduced 
in the first place.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#684315: Configuration file

[Roman Mamedov]

Here is my thinkfan.conf.

It had not changed since version 0.7.3 and that version works properly with it.



sensor /sys/devices/virtual/hwmon/hwmon0/temp1_input
fan /sys/class/hwmon/hwmon0/pwm1

(0, 0, 63)
(1, 61, 66)
(2, 64, 68)
(3, 66, 32767)



-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#679854: [lighttpd] Please assume /var/log/ can be volatile

[Roman Mamedov]

Package: lighttpd
Version: 1.4.31-1
Severity: wishlist

Hello,

On various embedded systems running from a flash disk with limited number of
overwrite cycles it might be desirabe to mount /var/log as tmpfs, especially
if long-term storage of logs is not required (but logs are still useful for
immediate debugging).

Currently lighttpd properly assumes that /var/run can be volatile and does
this in /etc/init.d/lighttpd:


if [ $1 != status ]; then
# be sure there is a /var/run/lighttpd, even with tmpfs
# The directory is defined as volatile and may thus be non-existing
# after a boot (DPM §9.3.2)
if ! dpkg-statoverride --list /var/run/lighttpd /dev/null 21; then
install -d -o www-data -g www-data -m 0750 /var/run/lighttpd
fi
fi


I propose that /var/log/lighttpd would be also checked and recreated in a 
similar manner.

Thanks


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.4.3-rm1+

Debian Release: wheezy/sid
  990 testing wheezy.natsu.romanrm.ru 
  500 unstablewww.emdebian.org 
  500 stable  linux-libre.fsfla.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-
libattr1   (= 1:2.4.46-7) | 1:2.4.46-8
libbz2-1.0 | 1.0.6-3
libc6 (= 2.4) | 2.13-33
libfam0| 
libldap-2.4-2   (= 2.4.7) | 2.4.28-1.1
libpcre3 (= 8.10) | 1:8.30-5
libssl1.0.0 (= 1.0.0) | 1.0.1c-3
zlib1g(= 1:1.1.4) | 1:1.2.7.dfsg-13
perl   | 5.14.2-12
lsb-base  (= 3.2-14)  | 4.1+Debian7
 OR systemd  (= 29.1) | 
mime-support   | 3.52-1
libterm-readline-perl-perl | 1.0303-1


Recommends  (Version) | Installed
=-+-===
spawn-fcgi| 


Suggests   (Version) | Installed
-+-===
openssl  | 1.0.1c-3
rrdtool  | 
apache2-utils| 

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#676389: [nbd-client] sed: -e expression #6, char 30: unterminated `s' command

[Roman Mamedov]

Package: nbd-client
Version: 1:3.1.1-1
Severity: normal

Setting up nbd-client (1:3.1.1-1) ...
sed: -e expression #6, char 30: unterminated `s' command
dpkg: error processing nbd-client (--configure):
 subprocess installed post-installation script returned error exit status 1

Did anyone test this at all?

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.2.18-rm1

Debian Release: wheezy/sid
  990 testing wheezy.natsu.romanrm.ru 
  500 unstablewww.emdebian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-==
libc6(= 2.4) | 2.13-32
debconf (= 0.5)  | 1.5.43
 OR debconf-2.0   | 
initscripts (= 2.88dsf-13.3) | 2.88dsf-22.1


Package's Recommends field is empty.

Package's Suggests field is empty.






-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#670126: [curl] Bad handling of IPv6 literal addresses

[Roman Mamedov]

Package: curl
Version: 7.25.0-1
Severity: normal

$ curl -v 2a02:1788:4fd:cd::c742:cde2
* About to connect() to 2a02:1788:4fd:cd::c742 port 80 (#0)
*   Trying 2a02:1788:4fd:cd::c742...

$ curl -v [2a02:1788:4fd:cd::c742:cde2]
curl: (3) [globbing] error: bad range specification after pos 2

Globbing is whatever, but the behavior in the first example is completely
wrong and unexpected.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.2.12-rm1

Debian Release: wheezy/sid
  990 testing wheezy.natsu.romanrm.ru 
  500 unstablewww.emdebian.org 
  500 stable  stable.natsu.romanrm.ru 

--- Package information. ---
Depends (Version) | Installed
=-+-=
libc6(= 2.7) | 2.13-27
libcurl3  (= 7.23.1) | 7.25.0-1
zlib1g   (= 1:1.1.4) | 1:1.2.6.dfsg-2


Package's Recommends field is empty.

Package's Suggests field is empty.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#670126: [curl] Bad handling of IPv6 literal addresses

[Roman Mamedov]

On Mon, 23 Apr 2012 10:41:31 +0200 (CEST)
Daniel Stenberg dan...@haxx.se wrote:

 This is known bug #30 in curl upstream:
 
   http://curl.haxx.se/docs/knownbugs.html
 
 Feel free to work on it!
 

Oh thank you very much, but please feel free to read my bug report a bit more
closely!

Okay, with -g

$ curl -gv 2a02:1788:4fd:cd::c742:cde2
* About to connect() to 2a02:1788:4fd:cd::c742 port 80 (#0)
*   Trying 2a02:1788:4fd:cd::c742...

Nothing changed. Note the IPv6 address specified and to where it actually
tries to connect. It seems to be a recent regression, this works properly in
at least version 7.21.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#670126: [curl] Bad handling of IPv6 literal addresses

[Roman Mamedov]

On Mon, 23 Apr 2012 11:04:02 +0200 (CEST)
Daniel Stenberg dan...@haxx.se wrote:

  * About to connect() to 2a02:1788:4fd:cd::c742 port 80 (#0)
  *   Trying 2a02:1788:4fd:cd::c742...
 
  Nothing changed.
 
 It changed drastically. Now it didn't complain on bad globbing. So your 
 original stated problem was exactly what I pointed to.

$ curl -v 2a02:1788:4fd:cd::c742:cde2
* About to connect() to 2a02:1788:4fd:cd::c742 port 80 (#0)
*   Trying 2a02:1788:4fd:cd::c742...
^C

$ curl -gv 2a02:1788:4fd:cd::c742:cde2
* About to connect() to 2a02:1788:4fd:cd::c742 port 80 (#0)
*   Trying 2a02:1788:4fd:cd::c742...
^C

Without the braces it never complains about bad globbing, but always chops
off the last part of this address (as of version 7.25), which is what the bug
report is about.

 You mean you could pass in an illegal URL back then and it happened to guess 
 what you meant? If so, that was mostly good luck.

With the older version:

# curl --version
curl 7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 
libidn/1.15 libssh2/1.2.6
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp 
scp sftp smtp smtps telnet tftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

It works:

# curl -v 2a02:1788:4fd:cd::c742:cde2
* About to connect() to 2a02:1788:4fd:cd::c742:cde2 port 80 (#0)
*   Trying 2a02:1788:4fd:cd::c742:cde2... connected
* Connected to 2a02:1788:4fd:cd::c742:cde2 (2a02:1788:4fd:cd::c742:cde2) port 
80 (#0)
[snip]


-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#662786: [procps] top: abbreviate Megabyte and Kilobyte properly (not Mb, Kb)

[Roman Mamedov]

Package: procps
Version: 1:3.3.2-3
Severity: normal

Hello,

the new output for top uses Mb and Kb to abbreviate Megabyte and
Kilobyte. This is incorrect, see for example:

  https://en.wikipedia.org/wiki/Megabyte
It is commonly abbreviated as Mbyte or MB (compare Mb, for the megabit).

  https://en.wikipedia.org/wiki/Megabit
The megabit has the unit symbol Mbit or Mb.

Small b means bits. Megabyte should be abbreviated as MB, Kilobyte
as KB.

Also from what I see the values beside that label seem to measure RAM in
base-binary units, in which case MiB and KiB should be considered instead:

  https://en.wikipedia.org/wiki/Mebibyte

But I will make no statement about MB vs MiB here, this bug report is
only about the fact that using Mb and Kb as done currently, is
definitely not correct and should be changed.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.2.7-rm1+

Debian Release: wheezy/sid
  990 testing wheezy.natsu.romanrm.ru 
  500 unstablewww.emdebian.org 
  500 unstablesid.natsu.romanrm.ru 
  500 maverickppa.launchpad.net 
1 experimentalexperimental.natsu.romanrm.ru 

--- Package information. ---
Depends  (Version) | Installed
==-+-==
libc6(= 2.11) | 2.13-26
libncurses5(= 5.5-5~) | 5.9-4
libncursesw5 (= 5.6+20070908) | 5.9-4
libprocps0  (= 1:3.3.2-1) | 1:3.3.2-3
libtinfo5  | 5.9-4
lsb-base   (= 3.0-10) | 3.2-28.1
initscripts| 2.88dsf-22


Recommends  (Version) | Installed
=-+-===
psmisc| 22.15-2


Package's Suggests field is empty.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#660072: [nut] Invalid udev rules prevent operation of nut

[Roman Mamedov]

On Thu, 16 Feb 2012 13:10:41 +0100
Arnaud Quette aquette@gmail.com wrote:

 Hi Roman,
 
 thanks for your report.
 
 2012/2/16 Roman Mamedov r...@romanrm.ru:
  Package: nut
  Version: 2.6.3-1
  Severity: important
 
  nut is completely broken on my system since quite some time ago.
 
  $ dpkg -S /etc/udev/rules.d/52-nut-usbups.rules
  nut: /etc/udev/rules.d/52-nut-usbups.rules
 
  $ debsums -e  nut
  /etc/udev/rules.d/52-nut-usbups.rules                                       
    OK
 
 this file is not anymore part of the NUT packages since 

Are you sure about that?

$ dpkg -l nut
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  nut2.6.3-1network UPS tools - metapackage

$ dpkg -L nut
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/nut
/usr/share/doc/nut/config-notes.txt.gz
/usr/share/doc/nut/scheduling.txt.gz
/usr/share/doc/nut/UPGRADING.gz
/usr/share/doc/nut/security.txt.gz
/usr/share/doc/nut/AUTHORS.gz
/usr/share/doc/nut/documentation.txt
/usr/share/doc/nut/support.txt
/usr/share/doc/nut/MAINTAINERS
/usr/share/doc/nut/changelog.Debian.gz
/usr/share/doc/nut/acknowledgements.txt.gz
/usr/share/doc/nut/copyright
/usr/share/doc/nut/changelog.gz
/usr/share/doc/nut/FAQ.txt.gz
/usr/share/doc/nut/download.txt.gz
/usr/share/doc/nut/nut-names.txt.gz
/usr/share/doc/nut/features.txt.gz
/usr/share/doc/nut/TODO.gz
/usr/share/doc/nut/NEWS.gz
/usr/share/doc/nut/user-manual.txt
/usr/share/doc/nut/packager-guide.txt.gz
/usr/share/doc/nut/README.gz
/usr/share/doc/nut/outlets.txt
/usr/share/doc/nut/history.txt.gz
/etc/nut/upssched.conf.sample
/etc/nut/upsmon.conf.sample
/etc/nut/upsd.users.sample
/etc/nut/ups.conf.sample
/etc/nut/upsd.conf.sample
/etc/udev/rules.d/52-nut-usbups.rules   
---

 the new one is located in /lib/udev, and has been updated to match the
 latest udev (Ie, there is no BUS reference anymore).
 
  /etc/nut/ups.conf.sample                                                    
    OK
  /etc/nut/upsmon.conf.sample                                                 
    OK
  /etc/nut/upsd.conf.sample                                                   
    OK
  /etc/nut/upssched.conf.sample                                               
    OK
  /etc/nut/upsd.users.sample                                                  
    OK
 
  ---
 
  Feb 16 11:48:33 natsu upsd[5477]: listening on 127.0.0.1 port 3493
  Feb 16 11:48:33 natsu upsd[5477]: listening on ::1 port 3493
  Feb 16 11:48:33 natsu upsd[5477]: Can't connect to UPS [pw800] 
  (blazer_usb-pw800): Permission denied
  Feb 16 11:48:33 natsu upsd[5477]: allowfrom in upsd.users is no longer used
  Feb 16 11:48:33 natsu upsd[5478]: Startup successful
  Feb 16 11:48:33 natsu upsmon[5481]: Startup successful
  Feb 16 11:48:35 natsu udevd[484]: unknown key 'BUS' in 
  /etc/udev/rules.d/52-nut-usbups.rules:6
  Feb 16 11:48:35 natsu udevd[484]: invalid rule 
  '/etc/udev/rules.d/52-nut-usbups.rules:6'
  Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
  /etc/udev/rules.d/52-nut-usbups.rules:10
  Feb 16 11:48:35 natsu udevd[484]: invalid rule 
  '/etc/udev/rules.d/52-nut-usbups.rules:10'
  ...
 
 could you please send back the following:
 - are you on testing or sid?

On testing.

 - which nut version you upgraded from (related to the above question)?

I run regular apt-get dist-upgrade so I am pretty much always on the latest
version in testing.

 - result of dpkg -l 'nut*'

$ dpkg -l 'nut*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  nut2.6.3-1network UPS tools - metapackage
un  nut-cginone (no description available)
ii  nut-client 2.6.3-1network UPS tools - clients
un  nut-devnone (no description available)
un  nut-hal-driversnone (no description available)
un  nut-monitornone (no description available)
ii  nut-server 2.6.3-1network UPS tools - core system
un  nut-snmp   none (no description available)
un  nut-usbnone (no description available)
un  nut-xmlnone (no description available)


 
 there may be something wrong in the upgrade path, following the
 various and invasive updates on the packages.
 
 cheers,
 Arnaud


-- 
With respect,
Roman

~~~
Stallman had

Bug#660072: [nut] Invalid udev rules prevent operation of nut

[Roman Mamedov]

Package: nut
Version: 2.6.3-1
Severity: important

nut is completely broken on my system since quite some time ago.

$ dpkg -S /etc/udev/rules.d/52-nut-usbups.rules
nut: /etc/udev/rules.d/52-nut-usbups.rules

$ debsums -e  nut
/etc/udev/rules.d/52-nut-usbups.rules OK
/etc/nut/ups.conf.sample  OK
/etc/nut/upsmon.conf.sample   OK
/etc/nut/upsd.conf.sample OK
/etc/nut/upssched.conf.sample OK
/etc/nut/upsd.users.sampleOK

---

Feb 16 11:48:33 natsu upsd[5477]: listening on 127.0.0.1 port 3493
Feb 16 11:48:33 natsu upsd[5477]: listening on ::1 port 3493
Feb 16 11:48:33 natsu upsd[5477]: Can't connect to UPS [pw800] 
(blazer_usb-pw800): Permission denied
Feb 16 11:48:33 natsu upsd[5477]: allowfrom in upsd.users is no longer used
Feb 16 11:48:33 natsu upsd[5478]: Startup successful
Feb 16 11:48:33 natsu upsmon[5481]: Startup successful
Feb 16 11:48:35 natsu udevd[484]: unknown key 'BUS' in 
/etc/udev/rules.d/52-nut-usbups.rules:6
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:6'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:10
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:10'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:14
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:14'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:18
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:18'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:20
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:20'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:24
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:24'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:26
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:26'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:28
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:28'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:30
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:30'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:32
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:32'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:34
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:34'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:36
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:36'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:38
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:38'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:42
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:42'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:46
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:46'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:48
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:48'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:50
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:50'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:52
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:52'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 
/etc/udev/rules.d/52-nut-usbups.rules:54
Feb 16 11:48:35 natsu udevd[484]: invalid rule 
'/etc/udev/rules.d/52-nut-usbups.rules:54'
Feb 16 11:48:35 natsu udevd[484]: unknown key 'SYSFS{idVendor}' in 

Bug#622325: linux-image-2.6.38-2-orion5x: Problem With I2C

[Roman Mamedov]

On Mon, 23 Jan 2012 14:27:50 -0600
Jonathan Nieder jrnie...@gmail.com wrote:

 Were you able to try backing out eda6bee6c7 (i2c-mv64xxx: send
 repeated START between messages in xfer) as Guenter suggested?

I have finally managed to do that, and indeed, this problem is solved by
rolling-back that commit. The same problem was observed with the current
vanilla 3.2.2, and only after the roll-back it started working fine:

root@mahou:~# uname -a
Linux mahou 3.2.2orion5x-rm1+ #3 Mon Jan 30 19:29:49 YEKT 2012 armv5tel 
GNU/Linux

root@mahou:~# sensors
g760a-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:4681 RPM

lm75-i2c-0-48
Adapter: mv64xxx_i2c adapter
temp1:+42.0°C  (high = +80.0°C, hyst = +75.0°C)

No errors in dmesg.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#622325: linux-image-2.6.38-2-orion5x: Problem With I2C

[Roman Mamedov]

On Sun, 1 Jan 2012 01:42:36 -0600
Jonathan Nieder jrnie...@gmail.com wrote:

  This bug is still present for me in the latest kernel version in
  Debian testing (3.1.6).
 
 Passed upstream.  But now I notice that there has been some upstream
 work in this area recently (v3.2-rc7~23^2~1, rtc: m41t80: Workaround
 broken alarm functionality, 2011-12-12).
 
 Please test v3.2-rc7 from experimental and let the upstream folks
 know how it fares (by replying-to-all on the other side thread).

Hello,

I have now upgraded to linux-image-3.1.0-1-orion5x (3.1.8-2) from testing.

According to http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.1.8
it has the rtc: m41t80: Workaround broken alarm functionality patch included.
However, it does not solve the problem. The messages continue to appear:

[   34.442094] mv643xx_eth_port mv643xx_eth_port.0: eth0: link up, 1000 Mb/s, 
full duplex, flow control disabled
[   34.452167] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   35.107852] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   37.107743] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   41.007743] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   43.007755] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   45.007747] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   47.007744] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   50.090809] mv643xx_eth_port mv643xx_eth_port.0: eth0: link up, 1000 Mb/s, 
full duplex, flow control disabled
[   85.637697] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   87.637699] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   89.637693] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   91.647701] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   93.647738] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[   95.647701] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0

Fan does not rotate (verified visually) and the temperature sensor does not 
work:

# sensors
g760a-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:   0 RPM

lm75-i2c-0-48
Adapter: mv64xxx_i2c adapter
temp1: +0.0°C  (high =  +0.0°C, hyst =  +0.0°C)

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#622325: linux-image-2.6.38-2-orion5x: Problem With I2C

[Roman Mamedov]

On Mon, 23 Jan 2012 14:27:50 -0600
Jonathan Nieder jrnie...@gmail.com wrote:

 Were you able to try backing out eda6bee6c7 (i2c-mv64xxx: send
 repeated START between messages in xfer) as Guenter suggested?  It
 works like this:

Hello,

If this had been a regular x86 machine I would have done this long ago :)
But I don't currently have a working ARM crosscompile environment [and the one
I'd trust enough to create non-bricking kernels], and building a kernel on the
device itself, with just 64 MB of RAM and 2GB of slow USB flash storage, might
not work well. I'll see if I can solve either problem in one way or the other,
and will post an update some time later.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#622683: Affects chromium

[Roman Mamedov]

Hello,

Since my previous message to this bug-report on 6 May 2011, I removed the 
aptitude hold of libcairo2 to version 1.8, as I noticed that at some point 
Iceweasel stopped crashing with the 1.10.

But now I am migrating to Chromium, and faced the same problem again. When 
starting Chromium in an Xvnc4 session, an attempt to switch tabs while not all 
tabs have finished loading their pages yet, very often results in Chromium 
crashing with the same _pixel_to_solid: Assertion `!reached' failed message.

Rolling back to libcairo2 version 1.8 is not an option anymore, because all of 
GTK 3 depends on the version 1.10.

I have found a different solution, specifically commenting out the offending 
ASSERT_NOT_REACHED in cairo-1.10.2/src/cairo-image-surface.c line 1320 (and 
rebuilding  installing the built package). This while not being a proper fix, 
seems to be enough to at least eliminate the Chromium crashes for me.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#622325: linux-image-2.6.38-2-orion5x: Problem With I2C

[Roman Mamedov]

On Sun, 1 Jan 2012 01:42:36 -0600
Jonathan Nieder jrnie...@gmail.com wrote:

 Passed upstream.  But now I notice that there has been some upstream
 work in this area recently (v3.2-rc7~23^2~1, rtc: m41t80: Workaround
 broken alarm functionality, 2011-12-12).
 
 Please test v3.2-rc7 from experimental and let the upstream folks
 know how it fares (by replying-to-all on the other side thread).

Hello,

Thank you for looking into this and for the information about the 3.2 possible 
fix.
Unfortunately I can't try that kernel easily at the moment, as there doesn't 
seem to be an orion5x variant of the package in experimental.

Some more info:

- During my testing I have found that after booting with a 'bad' kernel, a full 
power-off of the device including disconnecting the power supply from the mains 
might be required, before a 'good' kernel will work properly.

- This might have been mentioned, but the main reason this bug concerns me, is 
that the temperature sensor and the fan PWM control do not work on the 'bad' 
kernels (i.e. it's not just the periodic dmesg error). The fan does not turn 
on, which risks overheating the device and/or drives.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#622325: Still occurs in 3.1+

[Roman Mamedov]

Hello,

This bug is still present for me in the latest kernel version in Debian testing 
(3.1.6).

The last properly working kernel version seems to be:
http://snapshot.debian.org/archive/debian/20110217T214513Z/pool/main/l/linux-2.6/linux-image-2.6.37-1-orion5x_2.6.37-1_armel.deb

And the problem occurs since:
http://snapshot.debian.org/archive/debian/20110301T040946Z/pool/main/l/linux-2.6/linux-image-2.6.37-2-orion5x_2.6.37-2_armel.deb

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#652064: vnc4server opens only IPv6 socket but there IPv4 address available

[Roman Mamedov]

On Wed, 14 Dec 2011 16:02:21 +0100 (CET)
Neszt Tibor ti...@neszt.hu wrote:

 I saw this bug was fixed in #562169, but it seems, this is still an 
 existsing problem:
 
 # lsof -n | grep 5901
 Xvnc4  1174  neszt3u IPv6   13886440   0t0TCP 
 *:5901 (LISTEN)
 
 My main network interface has both IPv4 and IPv6 addresses, and there are 
 other network interfaces.

Hello,

This is not a problem, because you can connect to this socket via using both 
IPv4 and IPv6:

$ sudo lsof -n | grep 5901 | grep LISTEN
Xvnc4  4955 rm3u IPv6  163680t0
TCP *:5901 (LISTEN)

$ nc6 -vvv4 localhost 5901
nc6: localhost (127.0.0.1) 5901 [5901] open
nc6: using stream socket
nc6: using buffer size of 8192
nc6: read 12 bytes from remote
RFB 003.008
nc6: wrote 12 bytes to local

$ nc6 -vvv6 localhost 5901
nc6: ip6-localhost (::1) 5901 [5901] open
nc6: using stream socket
nc6: using buffer size of 8192
nc6: read 12 bytes from remote
RFB 003.008
nc6: wrote 12 bytes to local

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#652100: [bash] Does not handle Unicode properly anymore

[Roman Mamedov]

Package: bash
Version: 4.2-1
Severity: normal

Bash 4.1:

# проверка
-bash: проверка: command not found

Bash 4.2:

# проверка
-bash: $'\320\277\321\200\320\276\320\262\320\265\321\200\320\272\320\260': 
command not found

locale in both cases is:

LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

That is all.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.1.1-for-workgroups+

Debian Release: wheezy/sid
  500 unstablewww.emdebian.org 
  500 testing wheezy.natsu.romanrm.ru 
  500 maverickppa.launchpad.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-
base-files  (= 2.1.12) | 6.5
debianutils   (= 2.15) | 4.1


Recommends(Version) | Installed
===-+-
bash-completion (= 20060301-0) | 1:1.3-1


Suggests  (Version) | Installed
===-+-===
bash-doc| 







-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#648938: Affects mysql-client-5.1

[Roman Mamedov]

Hello,

This crap has now spread into testing and broke my backups done via 
mysql-client-5.1: /usr/bin/mysqldump

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#648938: Affects mysql-client-5.1

[Roman Mamedov]

On Wed, 23 Nov 2011 10:24:23 +0600
Roman Mamedov r...@romanrm.ru wrote:

 Hello,
 
 This crap has now spread into testing and broke my backups done via 
 mysql-client-5.1: /usr/bin/mysqldump
 

Nope, sorry, the affected program is actually not mysqldump, but 
http://packages.debian.org/sendemail

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#644989: Still not fixed

[Roman Mamedov]

reopen 644989 !
thanks

Hello,

With e2fsprogs 1.42~WIP-2011-10-16-1 and

Linux hoshi 3.1.0-libre-lemote-rm2-mfgpt #2 Fri Nov 11 03:07:23 YEKT 2011 
mips64 GNU/Linux

This bug still happens:

# resize2fs /dev/sda2
resize2fs 1.42-WIP (16-Oct-2011)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
resize2fs: Invalid argument While checking for on-line resizing support

# dumpe2fs -h /dev/sda2 
dumpe2fs 1.42-WIP (16-Oct-2011)
Filesystem volume name:   root
Last mounted on:  /
Filesystem UUID:  05909bf1-6835-48f2-be0e-8ed0355a4dad
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr resize_inode dir_index filetype 
needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg 
dir_nlink extra_isize
Filesystem flags: signed_directory_hash 
Default mount options:(none)
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  446160
Block count:  1782272
Reserved block count: 0
Free blocks:  1358241
Free inodes:  371133
First block:  0
Block size:   4096
Fragment size:4096
Reserved GDT blocks:  435
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8112
Inode blocks per group:   507
Flex block group size:16
Filesystem created:   Mon Mar 14 16:31:05 2011
Last mount time:  Wed Nov 16 02:14:25 2011
Last write time:  Sun Jul  3 00:06:22 2011
Mount count:  16
Maximum mount count:  23
Last checked: Sun Jul  3 00:06:22 2011
Check interval:   15552000 (6 months)
Next check after: Fri Dec 30 00:06:22 2011
Lifetime writes:  18 GB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 28
Desired extra isize:  28
Journal inode:8
Default directory hash:   half_md4
Directory Hash Seed:  340ff49e-7e0b-4eb5-9b8c-b5ff6d391b68
Journal backup:   inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length:   32768
Journal sequence: 0x00013d0d
Journal start:1


-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#644989: Still not fixed

[Roman Mamedov]

On Tue, 15 Nov 2011 16:38:18 -0500
Ted Ts'o ty...@mit.edu wrote:

 Are you using a 32-bit or 64-bit userspace with this 64-bit kernel?
 Because I can't replicate the problem, and in fact everyone else was
 complaining when we were checking for EINVAL instead of ENOTTY (which
 is what should be returned).

Hello,

I am using a 32-bit userspace.

# file `which resize2fs`
/sbin/resize2fs: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.26, 
BuildID[sha1]=0x03c020b8cf725f54a2e6de2aa539a624d8116074, with unknown 
capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x104, 
stripped

# strace resize2fs /dev/sda2
execve(/sbin/resize2fs, [resize2fs, /dev/sda2], [/* 15 vars */]) = 0
brk(0)  = 0x42
old_mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x77874000
uname({sys=Linux, node=hoshi, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=35820, ...}) = 0
old_mmap(NULL, 35820, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7783c000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/mipsel-linux-gnu/libe2p.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0 \21\0\0004\0\0\0..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=36784, ...}) = 0
old_mmap(NULL, 99904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7782
mprotect(0x77828000, 65536, PROT_NONE)  = 0
old_mmap(0x77838000, 16384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x77838000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/mipsel-linux-gnu/libext2fs.so.2, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\340v\0\0004\0\0\0..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=404288, ...}) = 0
old_mmap(NULL, 445968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x777b
mprotect(0x7780c000, 65536, PROT_NONE)  = 0
old_mmap(0x7781c000, 16384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5c000) = 0x7781c000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/mipsel-linux-gnu/libcom_err.so.2, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\\r\0\0004\0\0\0..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=13576, ...}) = 0
old_mmap(NULL, 76928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7779c000
mprotect(0x777a, 49152, PROT_NONE)  = 0
old_mmap(0x777ac000, 16384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x777ac000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/mipsel-linux-gnu/libc.so.6, O_RDONLY) = 3
read(3, 
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\344s\1\0004\0\0\0..., 512) = 
512
lseek(3, 760, SEEK_SET) = 760
read(3, \4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\32\0\0\0, 32) 
= 32
fstat64(3, {st_mode=S_IFREG|0755, st_size=1595104, ...}) = 0
old_mmap(NULL, 1580672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x77618000
mprotect(0xc000, 65536, PROT_NONE)  = 0
old_mmap(0x7778c000, 49152, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x164000) = 0x7778c000
old_mmap(0x77798000, 7808, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x77798000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/mipsel-linux-gnu/libpthread.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0`K\0\0004\0\0\0..., 
512) = 512
lseek(3, 744, SEEK_SET) = 744
read(3, \4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\32\0\0\0, 32) 
= 32
fstat64(3, {st_mode=S_IFREG|0755, st_size=135053, ...}) = 0
old_mmap(NULL, 172992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x775ec000
mprotect(0x77604000, 49152, PROT_NONE)  = 0
old_mmap(0x7761, 32768, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7761
close(3)= 0
set_thread_area(0x7787dca0) = 0
mprotect(0x7761, 16384, PROT_READ)  = 0
mprotect(0x7778c000, 32768, PROT_READ)  = 0
munmap(0x7783c000, 35820)   = 0
set_tid_address(0x77876878) = 1762
SYS_4309()  = 0
futex(0x7fefacd0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) = 
-1 EINVAL (Invalid argument)
rt_sigaction(SIGRT_0, {0x8, [], 

Bug#644989: Still not fixed

[Roman Mamedov]

Hello,

I have just tried the version from Squeeze (1.41.12-4stable1), and it does work 
properly:

# resize2fs /dev/sda2
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/sda2 to 1844772 (4k) blocks.
The filesystem on /dev/sda2 is now 1844772 blocks long.

-- 
With respect,
Roman

~~~
Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free.


signature.asc
Description: PGP signature

Bug#643303: [weborf] Can not be used 'out of the box'?

[Roman Mamedov]

On Tue, 27 Sep 2011 23:04:12 +0200
Salvo Tomaselli tipos...@tiscali.it wrote:

 Greetings,
 
 by default weborf doesn't allow the following methods to work:
 PUT,PROPFIND,DELETE,COPY,MOVE
 
 to avoid indiscriminate access to the server from remote. They only work when 
 authentication is in use.
 
 Yes you are correct, without the authentication socket you can't have write 
 access on the server.

I can't get *any* access to the server, even read-only. It seems like the DAV 
filesystems (tried with davfs2 and fusedav packages from Debian) issue 
PROPFIND at all times, even when no writes are attempted.

Also, is PROPFIND really a write operation? From 
http://www.webdav.org/specs/rfc2518.html#METHOD_PROPFIND, that doesn't look to 
be the case. It just allows to read properties of a file/directory. Modifying 
those is done via PROPPATCH.

 There are examples in C and python in /usr/share/doc/weborf/examples, and you 
 might want to try the qweborf package, that provides a GUI for enabling DAV 
 and write on the server without doing any programming.

I'd like to use WebDAV on machines with no GUI installed.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#643303: [weborf] Can not be used 'out of the box'?

[Roman Mamedov]

Package: weborf
Version: 0.13-1
Severity: normal

Hello,

On the server I run:

   weborf -b /tmp/ -p 8080

On the client:

  fusedav http://server.tld:8080/ test/

Messages on the client:

  PROPFIND failed: 403 Forbidden
  PROPFIND failed: 403 Forbidden

Any attempt to access test/ on the client results in repeating messages like 
the above.

The documentation to weborf talks about the need for a separate program to 
handle authentication, and that its unix socket must be passed via the -a 
argument to weborf. So am I expected to write (or modify from examples) such a 
program, and that weborf is completely unusable without it? Even if I want just 
something simple, e.g. read-only access to all users, or write access to all 
users?


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.4-rm1

Debian Release: wheezy/sid
  500 unstablewww.emdebian.org 
  500 testing wheezy.natsu.romanrm.ru 
  500 maverickppa.launchpad.net 

--- Package information. ---
Depends(Version) | Installed
-+-===
libc6 (= 2.3.2) | 2.13-21
libmagic1| 5.08-1


Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
php5-cgi (= 5.2.11.dfsg.1) | 5.3.8-2







-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#639540: [approx] Can not be mirrored by debmirror (denies Packages.bz2)

[Roman Mamedov]

On Sat, 27 Aug 2011 19:44:53 -0400
Eric Cooper e...@cmu.edu wrote:

 I suppose I could allow approx to fetch .bz2 and other compressed
 versions if pdiffs are disabled ($pdiffs false) -- would that be
 useful?

I suppose that could be useful.

Or perhaps better, the ability to select which of the Packages is allowed, I 
believe if I could choose e.g. to allow only .bz2 instead of only .gz, this 
would solve the problem without causing other apps to fail, and without 
forgoing pdiffs, just with a small time cost because of bz2 vs gz higher 
complexity.

 Otherwise the only way to make debmirror work with approx would be if
 it can be told to use .gz files instead of .bz2.  (I haven't used it,
 so I don't know.)

I couldn't find anything of this sort in its man page.


-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#639540: [approx] Can not be mirrored by debmirror (denies Packages.bz2)

[Roman Mamedov]

Package: approx
Version: 5.1-1
Severity: normal

Here is the output I get from debmirror:
--
Getting meta files ...
[  0%] Getting: dists/wheezy/Release #** GET 
http://natsu.romanrm.ru:9998/debian/dists/wheezy/Release == 200 OK
ok
[  0%] Getting: dists/wheezy/Release.gpg #** GET 
http://natsu.romanrm.ru:9998/debian/dists/wheezy/Release.gpg == 200 OK
ok
gpgv: keyblock resource `/root/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Sat Aug 27 14:22:19 2011 YEKT using RSA key ID 473041FA
[GNUPG:] ERRSIG AED4B06F473041FA 1 2 00 131449 9
[GNUPG:] NO_PUBKEY AED4B06F473041FA
gpgv: Can't check signature: public key not found
Release gpg signature does not verify.
[ 86%] Getting: dists/wheezy/main/binary-amd64/Packages.bz2  #** GET 
http://natsu.romanrm.ru:9998/debian/dists/wheezy/main/binary-amd64/Packages.bz2 
== 404 Not Found
dists/wheezy/main/binary-amd64/Packages.bz2 failed 404 Not Found
Errors:
 Download of dists/wheezy/main/binary-amd64/Packages.bz2 failed: 404 Not Found
 dists/wheezy/main/binary-amd64/Packages.bz2 failed checksum verification, 
removing
Failed to download some Package, Sources or Release files!
WARNING: releasing 1 pending lock...
--

Doing a manual request to see the directory contents shows that Packages.bz2 is 
virtually there:

$ curl -s http://natsu.romanrm.ru:9998/debian/dists/wheezy/main/binary-amd64/ | 
html2text 
** Index of /debian/dists/wheezy/main/binary-amd64 **
Name   Last_modified  Size
===
Parent_Directory-
Packages.bz2   27-Aug-2011 23:06  6.9M
Packages.diff/ 27-Aug-2011 17:14-
Packages.gz27-Aug-2011 23:06  9.1M
Release27-Aug-2011 23:23   82
===

But any attempt to download it simply results in a 404 error, hence debmirror 
fails to function properly.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.3-rm1

Debian Release: wheezy/sid
  500 unstablewww.emdebian.org 
  500 testing wheezy.natsu.romanrm.ru 
  500 maverickppa.launchpad.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
debconf   (= 0.5)  | 1.5.40
 OR debconf-2.0 | 
libc6  (= 2.7) | 2.13-16
libpcre3  (= 8.10) | 8.12-4
adduser | 3.113
curl| 7.21.7-1
openbsd-inetd   | 0.20091229-1
 OR inet-superserver| 
update-inetd| 4.39


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
libconfig-model-approx-perl| 







-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#625457: Broken Packages

[Roman Mamedov]

 Attached is a patch that should do just that. But maybe it breaks fetching an 
 unpacked Packages file, if that should be allowed.

And in fact it totally does, only one update completes successfully, after that 
all clients get the error 404 trying to fetch Packages (not gz, not bz2, this 
exact filename), and according to approx cache dir contents, it only has 
Packages.gz.

--
Hit http://natsu.romanrm.ru wheezy InRelease
Ign http://natsu.romanrm.ru wheezy/main amd64 Packages/DiffIndex
Ign http://natsu.romanrm.ru wheezy/main TranslationIndex
Err http://natsu.romanrm.ru wheezy/main amd64 Packages
  404  Not Found
Ign http://natsu.romanrm.ru wheezy/main Translation-en_US
Ign http://natsu.romanrm.ru wheezy/main Translation-en
W: Failed to fetch 
http://natsu.romanrm.ru:9998/debian/dists/wheezy/main/binary-amd64/Packages  
404  Not Found

E: Some index files failed to download. They have been ignored, or old ones 
used instead.
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
--

In this state the clients can not update from approx anymore at all, until the 
cache dir is manually cleared out (after which Packages can be successfully 
fetched from the remote repository). So I delete 
/var/cache/approx/debian/dists/wheezy/main/binary-amd64/Packages.gz, and update 
succeeds (once).

Did you even test this patch at all?

-- 
With respect,
Roman


signature.asc
Description: PGP signature