Bug#796609: fcoe-utils: Has init script in runlevel S but no matching service file
Hi Felipe, On Wed, Jan 25, 2017 at 03:00:29PM -0300, Felipe Sateler wrote: > > It is plenty usable, just not if you are using systemd. Yes, I am aware > > policy at this point requires systemd support. > > OK, sorry. The impression I had from your earlier message is that it > didn't work[1]. Ahh, I see. No, the package provides the utilities necessary to mount FCoE volumes, it just does not work when you try to mount them automatically at boot time. I would be curious how systemd accomplishes the necessary ordering if that is working with the systemd units. If so, when I have some time I will have to try and understand what systemd is doing. As far as I can tell this problem is not well solved, at least in sysvinit. NFS has a special arrangement. FCoE and iSCSI can't work as far as I can tell because the network must come up in order to discover volumes, but aside from NFS, volumes are mounted before the network is brought up. If Debian has a provision to mark f.e. an ext4 volume as a network volume in /etc/fstab, I do not know about it. Additionally, in sysvinit the network is stopped before unmounting volumes, so when the system attempts to unmount the FCoE volumes, the network is already down and the system waits forever for the volumes to unmount. Both of these problems can be worked around with kludgy init hacks that are not really a high enough quality to ship in Debian. Resolving these problems the right way is what I was referring to when I said the init scripts need work. > 0030-fcoe.service-Add-foreground-to-prevent-fcoemon-to-be.patch > > => Seems to me it is better to change the unit to Type=forking > instead? This way, systemd would know when the monitor is ready. Given the description of Type=forking that does sound sensible. > debian/rules: > > => it seems weird to me that the socket is not started by default. Maybe something to do with the hack-y version of dealing with forking? Thanks, -Jacob
Bug#796609: fcoe-utils: Has init script in runlevel S but no matching service file
Hi Felipe, On Wed, Jan 25, 2017 at 11:50:33AM -0300, Felipe Sateler wrote: > Apparently, fcow-utils as currently packaged is not usable in > debian. It is plenty usable, just not if you are using systemd. Yes, I am aware policy at this point requires systemd support. > Jacob Luna Lundberg, Liang Guo, could you please review and upload > this patch? I can't review the systemd components. I do not use systemd and I am unfamiliar with its configuration. Also, I am not a DD, so although I could upload the patch to the repository, I can't upload a package. There are (as mentioned) a few bugs in the current package, so if there has been an upstream release, we should really incorporate that as well. Some of the patches merged into this jumbo patch also sound like a good idea for inclusion into Debian. I can (will) look into all of the non-systemd parts in a month or so when my schedule settles a bit. I would be inclined to just accept the systemd parts as submitted given they seem to have seen some testing already. Thanks, -Jacob
Bug#753516: xscorch: fails to parse its data file
On Wed, Jul 02, 2014 at 07:29:33PM +0200, Yann Dirson wrote: > Not sure since when it started to fail, but it does not start up at all today: Since the +b1; I assume there must have been API changes. Thank you for taking the time to report this. I am going to try and get it taken care of before we freeze testing, but my time is in short supply right now. -Jacob -- "Dude! Your hair! It looks... different." 'Budget increase.' "HOLY SHIT!! We actually have a budget?!?" - Alex LaCroix and Siobhan Armittage, Ghost 2138 (the web comic) signature.asc Description: Digital signature
Bug#708123: grub2 (2.00-14) fails to install on v0.90 RAID1 arrays
I rebuilt my root array with a modern superblock and now grub handles it just fine. This problem is most likely specific to the old v0.90 layout. So it's still a bug in grub but I can't help test any fixes anymore. However, this does provide a (painful) way forward for people hitting the bug -- rebuild your root array with a v1.x format... Thanks, -Jacob -- No. That's where you're wrong. This is reality. It is a self- sustaining ecosociosystem powered by inter-universe warp generators. - Fred Fine, "The Big U" by Neal Stephenson -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708123: grub2 (2.00-14) fails to install on RAID1 arrays
I can confirm this bug report. I also have root RAID 1 (and it's an old RAID volume created August 12th, 2005 so probably on an etch system). Upgrading to grub-pc 2.00-14 rendered my system unbootable (in the grub recovery console, my disks showed up but all their partitions were missing). Downgrading back to 1.99-27+deb7u1 allowed me to boot once more. If there is any further information I can provide to help, just let me know. Thanks, -Jacob -- Reechani, Sentrosi, Vasi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636188: xscorch: Please transition to use libreadline6-dev
Hi, On Tue, Aug 02, 2011 at 01:31:46AM +0800, Aron Xu wrote: > As you have written "libreadline5-dev | libreadline6-dev", then I assume > you have the sense that there is probably license issue with > libreadline6-dev, so you choose libreadline5-dev over it by default, and > you keep the latter one because it might be useful for those who want to > compile binary packages themselves. Actually, I was unaware of the license issue and don't really care what version of readline is used. XScorch works fine with both. I looked for libreadline-dev which would have been most convenient and when I didn't find it, I wrote a dep on both so I could still compile the package on older systems. The issue with the buildds using only the first dep is new to me and I really appreciate the information. I will start writing deps newest-to-oldest in my control files. > OK, then you need to check whether your build is correct, by running > lintian *and* checking the build log at least. You have tested it with > lintian already, then you forgot to check your log. I checked the log. It built fine. I didn't see any output I considered significant. However, I wasn't aware of the GPL issue. My omniscience level has been a bit low lately. Thanks, -Jacob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636188: xscorch: Please transition to use libreadline6-dev
Hi, On Mon, Aug 01, 2011 at 09:07:37PM +0800, Aron Xu wrote: > retitle 636188 Please use libreadline-gplv2-dev instead of libreadline5-dev > thanks I will prepare a new version using libreadline-gplv2-dev. Thank you for pointing out the license issue. > Again, please check your package is buildable with pbuilder/cowbuilder > or even in a plain sid chroot. As the package's maintainer, it's your > responsibility to make sure all of the problems do not exist before > you ask for sponsorship. I don't appreciate this comment. The package built on my sid desktop and using pbuilder on sid both i386 and amd64 yesterday. I still have the logs and here's what it said about that dep: pbuilder-satisfydepends-dummy depends on libreadline5-dev | libreadline6-dev; however: Package libreadline5-dev is not installed. Package libreadline6-dev is not installed. [...] Get: 95 http://http.us.debian.org/debian/ sid/main libreadline6-dev i386 6.2-2 [247 kB] [...] Selecting previously deselected package libreadline6-dev. Unpacking libreadline6-dev (from .../libreadline6-dev_6.2-2_amd64.deb) ... [...] dpkg-buildpackage: full upload (original source is included) You seem to have some mistaken information about pbuilder, or at least specific to your own installation of it. BTW I also ran it through lintian. Thanks, -Jacob -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622023: xscorch: FTBFS: sdisplay.c:34:4: error: lvalue required as left operand of assignment
Ahh, the joys of GDK/GTK and their ever-changing APIs. If only somebody would give me a nickel for every time the deprecate an interface... I have a new package built so once I get someone to upload it for me, this will be fixed, until a month from now when they break some other interface instead. Thanks, -Jacob -- Hail Ilpallazzo! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#346856: security bug needs upload along with xlibs-dev transition Re: Bug#346856: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 10:45:05AM -0800, Jacob Luna Lundberg wrote: > On Tue, Jan 17, 2006 at 02:37:52AM -0800, Steve Langasek wrote: > > Well, I can't confirm this. Jacob, please consider the attached > > patch, which fixes some quoting issues in configure.ac and > > re-autoconfs the source. Confirmed to work in pbuilder here. If you > > would care to prepare a -4 that includes these fixes, I'd be happy to > > sponsor for you (as, I imagine, would Thomas). > > Funky, I thought we were using libxpm directly for a few things. I'll > try to verify and get the -4 updated later today. Ok, I guess we tossed out the direct xpm bits a while ago. I've applied your patch and also updated the debhelper compatibility. Sorry this took longer than "later today"... If you or Thomas can do the upload for me, that would be great. The updated version can be downloaded from: http://www.gnifty.net/code/xscorch/ Thanks again everybody, -Jacob -- Hail Ilpallazzo! signature.asc Description: Digital signature
Bug#346856: security bug needs upload along with xlibs-dev transition Re: Bug#346856: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 02:37:52AM -0800, Steve Langasek wrote: > Is it confirmed that this stack smash bug is a security vulnerability? > Not all are... I am not aware of any security issues with this stack smash. You can overwrite up to 10 chars of stack but I certainly don't know how I would use it in a security attack. You would need to overwrite the scorings file, which is installed as root, or to edit the user's ~/.xscorch/config file and point them at a custom scorings file. I don't know enough about the stack layout in that function to say for sure whether it could be used to execute custom code or not, though. > Well, I can't confirm this. Jacob, please consider the attached > patch, which fixes some quoting issues in configure.ac and > re-autoconfs the source. Confirmed to work in pbuilder here. If you > would care to prepare a -4 that includes these fixes, I'd be happy to > sponsor for you (as, I imagine, would Thomas). Funky, I thought we were using libxpm directly for a few things. I'll try to verify and get the -4 updated later today. Thanks, -Jacob -- Hail Ilpallazzo! signature.asc Description: Digital signature
Bug#346856: intent to upload sponsored NMU to fix xlibs-dev bug
On Mon, Jan 16, 2006 at 05:45:44PM -0500, Justin Pryzby wrote: > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. My pbuild result of this patch was clean, and > produced a binary package with expected debdiff output from the most > recent version in sid. A build log is attached. Please consider using my package version 0.2.0-4 available here: http://www.gnifty.net/code/xscorch/ I requested that my usual sponsor do the upload a week ago but he hasn't had time yet. Thanks, -Jacob -- Hail Ilpallazzo! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
