Bug#1037039: rsyslog - SysV init file missing

[Narayanan R S]

Package: rsyslog
Version: 8.2302.0-1~bpo11+1

Can you please reinstate the missing /etc/init.d/rsyslog file in the
package?

>From the changelog notes, it appears to have been removed (intentionally)
in version 8.2110.0-2.

I'm not clear on why this is removed - one can continue to use a SysV init
and so this file is useful/important in systems that do not use systemd to
launch rsyslog. While I understand that ryslog's priority has been demoted
from important to optional (per
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018788), I see no reason
to exclude the SysV init file from the package

Thank you.

Narayanan.

Bug#858084: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#858084: linux-image-amd64 - kernel option enable request)

[Narayanan R S]

On Thu, Mar 30, 2017 at 5:13 PM, Ben Hutchings  wrote:

>
> > AFAIK, there's no (performance or size) penalty in enabling it [...]
>
> It's not very large, but yes there is a cost.
>
>
Is it enough to leave it disabled? It seems that being a (standard) sysfs
interface, the penalty is not really much at all (and considering all the
other stuff that we do have enabled in the kernel, especially for
convenience and/or usability, having this enabled shouldn't be an issue).

I hope you can consider enabling it.

Thanks.

Regards,

Narayanan.

Bug#858084: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#858084: linux-image-amd64 - kernel option enable request)

[Narayanan R S]

Hello,

AFAIK, there's no (performance or size) penalty in enabling it and it
provides some very convenient stats directly via sysfs. As a user of the
stats, it is very convenient just to have them ready and usable without
having to jump through hoops to access them.

I don't understand the reason for not enabling them. Is there any reason
*NOT* to enable it?

Thanks.

Regards,

Narayanan.

On Thu, Mar 30, 2017 at 4:45 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the linux-image-amd64 package:
>
> #858084: linux-image-amd64 - kernel option enable request
>
> It has been closed by Ben Hutchings <b...@decadent.org.uk>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings <
> b...@decadent.org.uk> by
> replying to this email.
>
>
> --
> 858084: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858084
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Ben Hutchings <b...@decadent.org.uk>
> To: 858084-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 30 Mar 2017 00:13:03 +0100
> Subject: Re: Bug#858084: linux-image-amd64 - kernel option enable request
> On Sat, 2017-03-18 at 10:16 +0530, Narayanan R S wrote:
> > Package: linux-image-amd64
> > Version: 4.9+79~bpo8+1
> >
> > Can you please enable the CONFIG_CPU_FREQ_STAT_DETAILS option for the
> > kernels.
>
> No, this is not really needed.  You can use the power:cpu_frequency
> tracepoint to see all transitions and then work out the statistics in a
> user-space program (or use bpfcc to do it in-kernel).
>
> Ben.
>
> --
> Ben Hutchings
> Everything should be made as simple as possible, but not simpler.
>- Albert
> Einstein
>
>
> -- Forwarded message --
> From: Narayanan R S <n...@kadamba.org>
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 18 Mar 2017 10:16:20 +0530
> Subject: linux-image-amd64 - kernel option enable request
> Package: linux-image-amd64
> Version: 4.9+79~bpo8+1
>
> Can you please enable the CONFIG_CPU_FREQ_STAT_DETAILS option for the
> kernels.
>
> Thanks in advance.
>
> Regards,
>
> Narayanan.
>
>

Bug#854677: linux-image-amd64 - patches from kernel source required

[Narayanan R S]

Hello,

I think this bug can be closed as the kernel version has been updated which
pretty much was the purpose of the original bug request.

Thank you.

Kind Regards,

Narayanan.

Bug#858084: linux-image-amd64 - kernel option enable request

[Narayanan R S]

Package: linux-image-amd64
Version: 4.9+79~bpo8+1

Can you please enable the CONFIG_CPU_FREQ_STAT_DETAILS option for the
kernels.

Thanks in advance.

Regards,

Narayanan.

Bug#854677: linux-image-amd64 - patches from kernel source required

[Narayanan R S]

Hi Ben,

I can try (re)running the 4.9 backport and see if the issue resurfaces.

What is the correlation between the debian kernel (backported) and the
mainline one (it says version 4.9.2-2~bpo8+1 - so is it essentially
_EXACTLY_ 4.9.2)?

Thanks.

Regards,

Narayanan.

On Fri, Feb 17, 2017 at 8:50 AM, Ben Hutchings <b...@decadent.org.uk> wrote:

> [Reply to all, not just to me.]
>
> On Fri, 2017-02-17 at 08:42 +0530, Narayanan R S wrote:
> > Hello Ben,
> >
> > I did have the documented ICMP network issues when I used the 4.9 version
> > of the backported kernel.
> >
> > When I reverted back to the 4.8 version (of the backported kernel),
> > everything was back to normal.
> >
> > I am not sure when in the 4.9 series this was fixed but the bug report
> > explicitly documents 4.9.5. I am not sure what version the backported
> > kernel + patches corresponds to in the official/mainstream 4.9 kernel.
>
> The fix is said to have been applied *before* 4.9 and confirmed as
> fixed in version 4.9.5.  There have been no fixes to netfilter between
> 4.9.2 (which I think you're using) and 4.9.5.
>
> So it sounds like you might have found a different bug.
>
> Ben.
>
> --
> Ben Hutchings
> Any sufficiently advanced bug is indistinguishable from a feature.
>
>

Bug#854677: linux-image-amd64 - patches from kernel source required

[Narayanan R S]

Package: linux-image-amd64
Version: 4.9+78

The current (backported) version of linux-image-amd64 (for Jessie) appears
to need a few important fixes from the kernel source (upstream).

Please see:

https://www.spinics.net/lists/kernel/msg2406212.html
https://bugzilla.redhat.com/show_bug.cgi?id=1402695

It appears that this has been fixed in the 4.9 series after 4.9.5 (per the
bugzilla link above) - so can the package be suitably updated to
incorporate this fix?

Thanks in advance.

Regards,

Narayanan.

Bug#703228: Any reasons for not including this fix?

[Narayanan R S]

Hi,

Is there any reason for not including this fix in the current version
of grub-legacy?

I have tested this patch for both ext4 functionality and gpt
functionality and it works perfectly.

Even though these fixes are available in grub2, I think it is useful
and doesn't require much effort to roll into grub-legacy.

Can the maintainers please comment?

If there's anything I can do to help please let me know.

Thanks.

Narayanan.


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

Bug#447556: wml: logos are completely broken - files are missing

[Narayanan R S]

Package: wml
Version: 2.0.11-1
Severity: important

wml::std::logo is totally broken as the logo files are missing. They 
should be present in /usr/lib/wml/data/logos/ but the logos directory is 
missing. Once you create the logos directory and put in the logo-*.info 
and logo-*.{gif|png} files things work fine. The original package is 
missing these files (and they are available from the source in the 
wml_misc directory). This probably took place between 2.0.8 and 2.0.11 
when the logo locations was moved from .../aux/ to .../data/logos.


This bug renders the entire wml::std::logo macro/package unusable.

Narayanan.




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

Bug#420933: ippl: patches to fix some critical bugs

[Narayanan R S]

Package: ippl
Version: 1.4.14-8
Severity: important

I've attached a new (additions on the existing diff file) diff file with some 
patches to fix a bunch of critical issues with ippl.


The summary is:

a) If you enable multiple protocol logs (eg: icmp+tcp+udp), there's a race 
condition due to which ippl will *NOT* run. The exact issue is that each thread 
drops (root) privileges after it attaches to the raw socket. If one of the 
other thread tries to attach after this drop in privileges it will fail and 
abort. The fix is to drop privileges in the main thread and not in each/every 
thread. There's a forced sleep in there to ensure that all the threads finish 
their socket attaches by then.


b) As a result of (a) (and of course it was a bug from before), it is no longer 
possible to reload the config files and reattach to the socket since the 
privilege drop has already happened. Reload were broken and now I've explicitly 
logged a message to restart instead of reload (the process will quit gracefully 
after logging).


The attached diff can be diffed with the previous diff from the source to get 
the exact changes I've made. Hopefully they are self explanatory.


Please forward this upstream.

Thanks.

Narayanan.

ippl_1.4.14-8.diff.gz
Description: Diffs for ippl patches

Bug#420958: ipac-ng: patches to fix some critical bugs

[Narayanan R S]

Package: ipac-ng
Version: 1.31-4
Severity: grave

I've attached a patch (this is the modified diff from the original 
source distribution) to fix an issue with ipac-ng when trying to use 
accounting that involves ports(with tcp and/or udp). Currently ipac-ng is 
broken as it cannot deal with ports due to a library load issue. This 
cropped up as a result of the sarge to etch upgrade and appears to be 
related to the change in the iptables libraries.


The summary of the change is the use of RTLD_LAZY instead of RTLD_NOW in 
the ipac-ng-1.31/agents/iptables/iptables.c file.


There are two references and I've changed them both to use LAZY. I've 
actually modified the sf1193721.dpatch file in debian/patches/ as this is 
the file that really fixes a bunch of other issues as well.


Without this fix, ipac-ng is completely broken and will _NOT_ even start 
if your config file has port matches for udp/tcp protocols.


This patch fixes the issue and ipac-ng runs perfectly for me (as it used 
to on sarge).


Please incorporate this (this exact fix can also be backported to the 
1.27-5 branch in case 1.31-4 cannot be bumped into stable, which I think 
should happen!).


The attached diff can be diffed with the previous diff from the source to 
get the exact changes I've made. Hopefully they are self explanatory.


They are:

###

$zdiff ipac-ng_1.31-4.diff.gz ipac-ng_1.31-4.diff.gz-ORIG
698c698
 @@ -0,0 +1,4847 @@
---

@@ -0,0 +1,4845 @@

947,948c947
 +- if (dlopen(path, RTLD_NOW)) {
 ++ if (dlopen(path, RTLD_LAZY)) {
---

+   if (dlopen(path, RTLD_NOW)) {

1071,1072c1070
 +- if (dlopen(path, RTLD_NOW)) {
 ++ if (dlopen(path, RTLD_LAZY)) {
---

+   if (dlopen(path, RTLD_NOW)) {


###

Please forward this upstream.

Thanks.

Narayanan.

ipac-ng_1.31-4.diff.gz
Description: ipac-ng patch (diff modification)

Bug#418906: vpnc: keepalive not implemented correctly

[Narayanan R S]

Package: vpnc
Version: 0.3.3+SVN20051028-3
Severity: important
Architecture: i386
Debian Release: Stable (etch)

vpnc doesn't correctly implement keepalives. The code ignores the user 
supplied keepalive time (seconds) and uses an internal poll timeout (which 
is 2 seconds). As a result, keep alives are sent every 2 seconds.


I'm attaching a patch (against the _ORIGINAL_ tunip.c file), which also 
incorporates the debian specific patch to the same file. The fix is quick 
and easy and updates the keepalive variable with the current time after 
every keep alive packet is sent, thus refreshing the next keep alive cycle 
to the user supplied value.


The exact two lines that need to change are:

// Save the new timestamp
keepalive = rekey = time(NULL);

(this is in the vpnc_main_loop function in tunip.c).

Please also forward this patch upstream to the vpnc codebase.

Thanks.

Narayanan.
*** tunip.c 2007-04-12 01:53:47.0 -0400
--- tunip.c.orig2007-04-12 01:53:47.0 -0400
*** static int tun_send_ip(struct encap_meth
*** 335,348 
return 1;
  }
  
! static int encap_esp_new(struct encap_method *encap, int encap_fd)
  {
  #ifdef IP_HDRINCL
int hincl = 1;
  #endif
  
!   encap-fd = encap_fd;
  
  #ifdef IP_HDRINCL
if (setsockopt(encap-fd, IPPROTO_IP, IP_HDRINCL, hincl, sizeof(hincl))
== -1) {
--- 335,352 
return 1;
  }
  
! static int encap_esp_new(struct encap_method *encap, unsigned char proto)
  {
  #ifdef IP_HDRINCL
int hincl = 1;
  #endif
  
!   encap-fd = socket(PF_INET, SOCK_RAW, proto);
  
+   if (encap-fd == -1) {
+   perror(socket(SOCK_RAW));
+   return -1;
+   }
  #ifdef IP_HDRINCL
if (setsockopt(encap-fd, IPPROTO_IP, IP_HDRINCL, hincl, sizeof(hincl))
== -1) {
*** int encap_esp_recv_peer(struct encap_met
*** 764,779 
  }
  
  static uint8_t volatile do_kill;
  
! #define VPNC_POLL_TIMEOUT 2000
! 
! static int vpnc_main_loop(struct peer_desc *peer, struct encap_method *meth, 
int tun_fd, const char *pidfile)
  {
struct pollfd pollfds[2];
-   time_t keepalive, rekey, now;
-   int rv = 1;
  
-   keepalive = rekey = time(NULL);
pollfds[0].fd = tun_fd;
pollfds[0].events = POLLIN;
pollfds[1].fd = encap_get_fd(meth);
--- 768,782 
  }
  
  static uint8_t volatile do_kill;
+ static uint8_t *kill_packet;
+ static size_t kill_packet_size;
+ static struct sockaddr *kill_dest;
  
! static void vpnc_main_loop(struct peer_desc *peer, struct encap_method *meth, 
int tun_fd, const char *pidfile)
  {
+   int sock;
struct pollfd pollfds[2];
  
pollfds[0].fd = tun_fd;
pollfds[0].events = POLLIN;
pollfds[1].fd = encap_get_fd(meth);
*** static int vpnc_main_loop(struct peer_de
*** 783,810 
int presult;
  
do {
!   presult = poll(pollfds, sizeof(pollfds) / 
sizeof(pollfds[0]), VPNC_POLL_TIMEOUT);
} while (presult == -1  errno == EINTR  !do_kill);
if (presult == -1) {
syslog(LOG_ERR, poll: %m);
continue;
}
  
-   now = time(NULL);
-   if (opt_nat_keepalive  (now - keepalive) = 
opt_nat_keepalive) {
-   const char *payload = \xff;
-   sendto(meth-fd, payload, 1, 0,
-   (struct sockaddr *)peer-remote_sa-dest, 
-   sizeof(peer-remote_sa-dest));
-   // Save the new timestamp
-   keepalive = rekey = time(NULL);
-   }
- 
-   if (opt_rekey_interval  now-rekey = opt_rekey_interval) {
-   rv = 0;
-   do_kill = 255;
-   }
- 
if (pollfds[0].revents  POLLIN) {
int pack;
  
--- 786,798 
int presult;
  
do {
!   presult = poll(pollfds, sizeof(pollfds) / 
sizeof(pollfds[0]), -1);
} while (presult == -1  errno == EINTR  !do_kill);
if (presult == -1) {
syslog(LOG_ERR, poll: %m);
continue;
}
  
if (pollfds[0].revents  POLLIN) {
int pack;
  
*** static int vpnc_main_loop(struct peer_de
*** 877,894 
}
}

!   if (rv != 0) {
!   tun_close(oursa-tun_fd, oursa-tun_name);
!   if (pidfile)
!   unlink(pidfile); /* ignore errors */
!   syslog(LOG_NOTICE, terminated);
!   }
!   return rv;
  }
  
  static void killit(int signum)
  {
do_kill = signum; /* unused */
  }
  
  static void write_pidfile(const char *pidfile)
--- 865,886 

Bug#418907: rdesktop: patch for segfaults with libx11-6 1.0.3-7 (stable)

[Narayanan R S]

Package: rdesktop
Version: 1.5.0-1
Severity: grave
Architecture: i386
Debian Release: Stable (etch)

After a recent update on stable, rdesktop segfaults repeatedly and is 
completely unusable. The root cause of this issue is a change in libx11-6 
(1.0.3-7) which had a recent security fix. The main issue is that the 
XCreateImage function has a change which impacts rdesktop (and other 
packages that depend on this library).


I'm attaching a patch that fixes this issue (I've tested it and it works 
perfectly on etch and is very stable).


The fix is against the xwin.c file (from the original rdesktop source 
distribution) in the rdesktop distribution.


Please update this ASAP since this is a critical bug and renders rdesktop 
completely unusable unless you downgrade to libx11-6 1.0.3-6.


Please forward the patch upstream.

Thanks.

Narayanan.
*** xwin.c  Wed Apr 11 12:31:43 2007
--- rdesktop-1.5.0/xwin.c   Mon Aug  7 07:45:44 2006
*** ui_create_glyph(int width, int height, u
*** 2413,2427 
g_create_glyph_gc = XCreateGC(g_display, bitmap, 0, NULL);
  
image = XCreateImage(g_display, g_visual, 1, ZPixmap, 0, (char *) data,
!width, height, 8, 0);
!   /* Patch to prevent Seg Faults - based on changes in libx11
!* to fix a security issue (CVE-2007-1667)
!* See: http://lists.debian.org/debian-x/2007/04/msg00052.html
!* See: 
http://www.nabble.com/Bug-418295:-vice-broken-by-libx11-security-update-t3544947.html
!* 
!* ORIGINAL: width, height, 8, scanline); 
!* NEW : width, height, 8, 0); 
!*/
image-byte_order = MSBFirst;
image-bitmap_bit_order = MSBFirst;
XInitImage(image);
--- 2413,2419 
g_create_glyph_gc = XCreateGC(g_display, bitmap, 0, NULL);
  
image = XCreateImage(g_display, g_visual, 1, ZPixmap, 0, (char *) data,
!width, height, 8, scanline);
image-byte_order = MSBFirst;
image-bitmap_bit_order = MSBFirst;
XInitImage(image);
*** ui_desktop_restore(uint32 offset, int x,
*** 3220,3254 
  {
XImage *image;
uint8 *data;
-   int bitmap_pad;
  
offset *= g_bpp / 8;
data = cache_get_desktop(offset, cx, cy, g_bpp / 8);
if (data == NULL)
return;
  
-   if (g_server_depth == 8)
-   {
-   bitmap_pad = 8;
-   }
-   else
-   {
-   bitmap_pad = g_bpp;
- 
-   if (g_bpp == 24)
-   bitmap_pad = 32;
-   }
- 
image = XCreateImage(g_display, g_visual, g_depth, ZPixmap, 0,
!   (char *) data, cx, cy, bitmap_pad, 0);
!   /* Patch to prevent Seg Faults - based on changes in libx11
!* to fix a security issue (CVE-2007-1667)
!* See: http://lists.debian.org/debian-x/2007/04/msg00052.html
!* See: 
http://www.nabble.com/Bug-418295:-vice-broken-by-libx11-security-update-t3544947.html
!* 
!* ORIGINAL: (char *) data, cx, cy, BitmapPad(g_display), cx * g_bpp / 
8); 
!* NEW : (char *) data, cx, cy, BitmapPad(g_display), 0); 
!*/
  
if (g_ownbackstore)
{
--- 3212,3225 
  {
XImage *image;
uint8 *data;
  
offset *= g_bpp / 8;
data = cache_get_desktop(offset, cx, cy, g_bpp / 8);
if (data == NULL)
return;
  
image = XCreateImage(g_display, g_visual, g_depth, ZPixmap, 0,
!(char *) data, cx, cy, BitmapPad(g_display), cx * 
g_bpp / 8);
  
if (g_ownbackstore)
{

Bug#361867: ~/.raggle/feeds.yaml zero-sized after crash

[Narayanan R S]

On Tue, 11 Apr 2006, Michael Ablassmeier wrote:


hi,


and immediately after this crash, ~/.raggle/feeds.yaml was zero-sized.
Luckily, there was still a usable ~/.raggle/feeds.yaml~ around.


im sorry to say im unable to reproduce this bug. Do you have a custom
configuration file you can send me? What did you do right before raggle
crashed? Did you Mark items as Unread or did this bug hit you out of
nowhere? Can you reproduce it with your backup feeds.yaml~?



Hi - I've run into this bug a few times and I've managed to 
(symptomatically) infer that this happens (to me) ONLY when raggle is 
saving the feed configuration (automatically every now and then) AND I use 
a key press like the cursor keys to select another window (item/desc/feed) 
as the active window. It's happened often enough that I've avoided using 
the arrow keys as much as possible (I don't want to disable the feed save 
feature).


I never got around to debugging it though.

I should think that you should be able to reproduce it if you use the 
arrow keys to move around a bunch of feeds (unhighlighting them possibly - 
since you're reading them) around the time an auto save kicks in.


HTH.

Nars.


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