Bug#881554: Pending upload for python-configshell-fb?
Hi Ritesh,
On Thu, 01 Aug 2019 17:43:25 +0530, Ritesh Raj Sarraf wrote :
> On Thu, 2019-08-01 at 11:55 +0200, Christophe Vu-Brugier wrote:
> > There is no bug report upstream, but I created a branch to remove the
> > epydoc dependency entirely a few days ago. This branch has not been
> > merge yet.
>
> So good to hear from you. :-)
>
> Glad that this is already reported upstream. But does those changes
> help with the documentation. Dropping epydoc is one part but then what
> else can/should we use as a replacement ?
From what I have seen, the epydoc markup in configshell-fb's docstrings
was not used to document the API. The epydoc markup was used as a
markup language to display help messages.
For instance, consider the help message for `ls` that is displayed when
the user types `help ls` in targetcli:
https://github.com/open-iscsi/configshell-fb/blob/master/configshell/node.py#L675
I{path} would have been displayed as italic in your console by the
render_domtree() giant function:
https://github.com/open-iscsi/configshell-fb/blob/master/configshell/console.py#L326
In truth, the "console" epydoc markup is not used because targetcli-fb
is built for Python 3 on Debian and cannot load epydoc.
With the epydoc specific markup removed, what is left is Javadoc
comments like:
'''
Initializes a Console instance.
@param stdin: The console standard input.
@type stdin: file object
@param stdout: The console standard output.
@type stdout: file object
'''
While epydoc can parse Javadoc comments, it seems that Sphinx does not
support them. So I don't know how the documentation package for
configshell-fb could be generated without epydoc. Maybe we can simply
drop this package... I don't think many developers read the API
documentation of configshell-fb.
With best regards,
--
Christophe Vu-Brugier
Bug#881554: Pending upload for python-configshell-fb?
Hi Ritesh, On Thu, 01 Aug 2019 14:24:59 +0530, Ritesh Raj Sarraf wrote : > Hello Kenneth, > > On Wed, 2019-07-31 at 21:17 -0500, Kenneth Pronovici wrote: > > Hi, > > > > I just wanted to follow up on python-configshell-fb. Back in June, > > you marked a pending upload to remove the epydoc dependency, but the > > bug is still open. I've filed the package removal request for > > epydoc, and I'm working through all of the reverse dependencies to > > adjust them, so the package removal can proceed. Could you please > > upload your new package sometime soon? It would help simplify things > > for me. > > So I didn't pay very close attention back when I disabled the > dependency on epydoc. > > Thing is, we are shipping a package for the documentation, python- > configshell-fb-doc, which contains the epydoc generated documentation > files. If I drop the epydoc dependency, I am left with an empty package > that I'll have to drop. I would rather prefer to see it still carry the > documentation. > > I just checked on the upstream project page and didn't see any bug > reports about the unmaintained epydoc dependency. Maybe they are > unaware of epydoc's current state. There is no bug report upstream, but I created a branch to remove the epydoc dependency entirely a few days ago. This branch has not been merge yet. See: https://github.com/open-iscsi/configshell-fb/pull/51 > I think best would be to migrate the documentation to the new sphinx > format you mentioned some time back. As for the documentation, there is not much epydoc markup in configshell-fb. It is mostly used to extract the message for the help commands from the docstrings (e.g. `help ls`, `help create`) and nicely format it to the console. Except that the nice formatting does not work most of the time because configshell-fb and targetcli-fb are running on Python 3 where epydoc is missing. Hope that helps, > My knowledge on documentation is very limited and so is the time these > days. So, if you can help me (or upstream directly) here, that'd help > expedite the upload without the epydoc dependency. > > Thanks, > Ritesh > -- Christophe Vu-Brugier
Bug#903500: python-rstlib-fb: I believe some changes are missing
Hi Thomas, On Fri, 24 Aug 2018 12:41:17 +0200, Thomas Goirand wrote : > I prefer to package 2.1.fb66, as this is what OpenStack gates on. OK. The difference is minor because version 2.1.fb66 and 2.1.fb67 differ only by a single commit. > Could you explain this? > https://salsa.debian.org/cvubrugier-guest/python-rtslib-fb/commit/01763af1f2303d06b127e23a20bb178e1505ac6f That's exactly the same as your patch in branch debian/rocky: https://salsa.debian.org/openstack-team/python/python-rtslib-fb/commit/14df33e261ee9e840784e8bff4d0e54552795b97 With your latest changes, I think the package is in good shape. It will allow us to upgrade targetcli-fb soon. Thanks! Cheers, -- Christophe Vu-Brugier
Bug#903500: python-rstlib-fb: I believe some changes are missing
Hi Thomas, Thank you for upgrading the python-rtslib-fb package but I believe some important changes are missing in the new package. * The main repository of python-rtslib-fb is now hosted by the Open-iSCSI organization on GitHub and the latest version there is newer 2.1.fb67 (instead of 2.1.fb66). Here is the URL of the new repo on GitHub: https://github.com/open-iscsi/rtslib-fb/ * python-rtslib-fb depends on pyudev since version 2.1.fb60. * Since the configuration directory for python-rtslib-fb is "/etc/rtslib-fb-target" instead of "/etc/target", the "preferred DB root" that contains PR and ALUA information should be updated as well. Otherwise, a crash will happen in targetcli-fb which is also patched on Debian to reflect the change in python-rtslib-fb. https://salsa.debian.org/cvubrugier-guest/python-rtslib-fb/commit/f33246d594f1795f89cd9704190f2b2216b9b350 You can have a look at the changes I pushed a few months ago on my repository on Salsa: https://salsa.debian.org/cvubrugier-guest/python-rtslib-fb/commits/debian/queens Please tell me if I can be of any help. With best regards, -- Christophe Vu-Brugier
Bug#903500: New upstream version?
Hi Thomas, On Wed, 11 Jul 2018 15:31:03 +0200, Thomas Goirand wrote : > I usually upload new versions of rtslib-fb together with new versions of > OpenStack, ie every 6 months. This is due for the end of this month. So > please do upload the new version to Experimental first, and then it will > go to unstable with everything else once OpenStack is released later > this summer. I can't upload a new version of rtslib-fb to Experimental because I am not a Debian developer. So you or another Debian maintainer / developer would have to do that. With best regards, -- Christophe Vu-Brugier
Bug#903500: New upstream version?
Hi Vagrant, On Tue, 10 Jul 2018 12:13:33 -0700, Vagrant Cascadian wrote : > Package: python-rtslib-fb > Version: 2.1.57+debian-4 > > It looks like the debian/watch file referencing fedorahosted.org no > longer works, but newer versions appear to be present upstream: > > https://github.com/agrover/rtslib-fb/releases: > >on 1 Mar 2017 v2.1.fb63 > > I might have some time to look into updating it as it's needed for > another project I'm working on, though that project is targeting Debian > stable for the moment. I worked on a branch to update python-rtslib-fb to the latest version (v2.1.fb67). Here is the Git repository if you want to give it a try: https://salsa.debian.org/cvubrugier-guest/python-rtslib-fb With best regards, -- Christophe Vu-Brugier pgpO358zmRvlc.pgp Description: Signature digitale OpenPGP
Bug#840356: initscripts: mountkernfs.sh does not mount configfs
Package: initscripts Version: 2.88dsf-59.8 Severity: normal Dear Maintainer, I am working on the targetcli-fb and python-rtslib-fb packages that rely on configfs and I think there is an issue in the mountkernfs.sh script that prevents it from mounting the configfs file system. The mount_filesystems() function in /etc/init.d/mountkernfs.sh contains the following code to mount the configfs file system under /sys/kernel/config: if [ -d /sys/kernel/config ] then domount "$MNTMODE" configfs "" /sys/kernel/config configfs "" fi The problem is that the /sys/kernel/config directory does not exist when the script is invoked because the configfs kernel module is not loaded at that time. The /sys/kernel/config directory does not exist until the configfs module is probed. See: http://lxr.free-electrons.com/source/fs/configfs/mount.c#L142 Invoking `modprobe configfs` before testing for /sys/kernel/config being a directory allows to mount configfs as expected. I am not sure it is the proper fix though. There was a similar issue reported for systemd: #800521 systemd: sys-kernel-config.mount not functional https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800521 The fix for this bug was to make the package install a configuration file in a modules-load.d directory to load the configfs module. I tried to do the same for sysv, expecting that the configfs module would be loaded before mountkernfs.sh is run, but it is not the case. Maybe we could cut the configfs section from mountkernfs.sh and put it in a separate mountconfigfs.sh init script that would start after kmod? What do you think? With best regards, -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages initscripts depends on: ii coreutils 8.25-2 ii debianutils 4.8 ii lsb-base9.20160629 ii mount 2.28.2-1 ii sysv-rc 2.88dsf-59.8 ii sysvinit-utils 2.88dsf-59.8 Versions of packages initscripts recommends: ii e2fsprogs 1.43.3-1 ii psmisc 22.21-2.1+b1 initscripts suggests no packages. -- no debconf information
Bug#838862: ITP: targetcli-fb -- Command shell for managing the Linux LIO kernel target
Package: wnpp Severity: wishlist Owner: "Christophe Vu-Brugier" <cvubrug...@fastmail.fm> * Package name: targetcli-fb Version : 2.1.43 Upstream Author : Andy Grover <agro...@redhat.com> * URL : https://github.com/open-iscsi/targetcli-fb * License : Apache-2.0 Programming Lang: Python Description : Command shell for managing the Linux LIO kernel target The targetcli-fb package is a command-line interface for configuring the LIO generic SCSI target, present since 3.x Linux kernel versions. The targetcli-fb package is a fork of the targetcli package and will replace it. I will co-maintain the package in the linux-target Alioth packaging project.
Bug#838861: ITP: python-configshell-fb -- Python library for building configuration shells
Package: wnpp Severity: wishlist Owner: "Christophe Vu-Brugier" <cvubrug...@fastmail.fm> * Package name: python-configshell-fb Version : 1.1.20 Upstream Author : Andy Grover <agro...@redhat.com> * URL : https://github.com/open-iscsi/configshell-fb * License : Apache-2.0 Programming Lang: Python Description : Python library for building configuration shells The python-configshell-fb package is a Python library that provides a framework for building simple but nice CLI-based applications. It is compatible with Python 3. The python-configshell-fb package is a fork of the python-configshell package and will replace it. It is a dependency of the targetcli-fb package which is a command-line interface for configuring the LIO generic SCSI target, present in the Linux kernel. An ITP bug for targetcli-fb will be submitted later. I will co-maintain the package in the linux-target Alioth packaging project.
Bug#676533: please enable arm assembler code in openssl
I tried the patch submitted by Riku Voipio that enables ARM assembler optimizations for ARM and it makes a big difference. For instance, on a Marvell Kirkwood 88F6281 (CPU Feroceon 88FR131 rev 1 @1.2GHz): benchmarkdebian with patch sha1 39305.22k -- 41343.57k aes-128 cbc 11517.95k -- 17571.84k aes-256 cbc 8523.52k -- 13213.70k sha256 13940.10k -- 28207.79k sha5122441.22k -- 12656.64k rsa 1024 1637.4v/s -- 3152.4v/s -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652869: Laptop auto power-on after correct shutdown and being powered-off
Hi Jonathan,
On Thu, 22 Dec 2011 04:28:12 -0600, Jonathan Nieder wrote :
Could you try this patch[1]?
[1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html
I experienced the bug with a Toshiba Portege R830 and Linux 3.1.6. I
followed your instructions and I rebuilt a kernel that reverts rtc:
Disable the alarm in the hardware. That works: my laptop does not
power on automagically after 5 minutes.
Thank you,
-- 8 --
Subject: Revert rtc: Disable the alarm in the hardware
This reverts commit 0cbc008c56f7b4a11ba6fe80e196d7ab322baabf.
---
Thanks and hope that helps,
Jonathan
drivers/rtc/interface.c | 44
++-- 1 files changed, 10
insertions(+), 34 deletions(-)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 3d9d2b976560..44e91e598f8d 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -318,20 +318,6 @@ int rtc_read_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alarm) }
EXPORT_SYMBOL_GPL(rtc_read_alarm);
-static int ___rtc_set_alarm(struct rtc_device *rtc, struct
rtc_wkalrm *alarm) -{
- int err;
-
- if (!rtc-ops)
- err = -ENODEV;
- else if (!rtc-ops-set_alarm)
- err = -EINVAL;
- else
- err = rtc-ops-set_alarm(rtc-dev.parent, alarm);
-
- return err;
-}
-
static int __rtc_set_alarm(struct rtc_device *rtc, struct rtc_wkalrm
*alarm) {
struct rtc_time tm;
@@ -355,7 +341,14 @@ static int __rtc_set_alarm(struct rtc_device
*rtc, struct rtc_wkalrm *alarm)
* over right here, before we set the alarm.
*/
- return ___rtc_set_alarm(rtc, alarm);
+ if (!rtc-ops)
+ err = -ENODEV;
+ else if (!rtc-ops-set_alarm)
+ err = -EINVAL;
+ else
+ err = rtc-ops-set_alarm(rtc-dev.parent, alarm);
+
+ return err;
}
int rtc_set_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
@@ -769,20 +762,6 @@ static int rtc_timer_enqueue(struct rtc_device
*rtc, struct rtc_timer *timer) return 0;
}
-static void rtc_alarm_disable(struct rtc_device *rtc)
-{
- struct rtc_wkalrm alarm;
- struct rtc_time tm;
-
- __rtc_read_time(rtc, tm);
-
- alarm.time = rtc_ktime_to_tm(ktime_add(rtc_tm_to_ktime(tm),
- ktime_set(300, 0)));
- alarm.enabled = 0;
-
- ___rtc_set_alarm(rtc, alarm);
-}
-
/**
* rtc_timer_remove - Removes a rtc_timer from the rtc_device
timerqueue
* @rtc rtc device
@@ -804,10 +783,8 @@ static void rtc_timer_remove(struct rtc_device
*rtc, struct rtc_timer *timer) struct rtc_wkalrm alarm;
int err;
next = timerqueue_getnext(rtc-timerqueue);
- if (!next) {
- rtc_alarm_disable(rtc);
+ if (!next)
return;
- }
alarm.time = rtc_ktime_to_tm(next-expires);
alarm.enabled = 1;
err = __rtc_set_alarm(rtc, alarm);
@@ -869,8 +846,7 @@ again:
err = __rtc_set_alarm(rtc, alarm);
if (err == -ETIME)
goto again;
- } else
- rtc_alarm_disable(rtc);
+ }
mutex_unlock(rtc-ops_lock);
}
--
Christophe Vu-Brugier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
