Ritesh Raj Sarraf (2021-05-15):
> That'd be nice of you. So, yes, please.
>
> And you'd be the next best team (debian-boot) to test that feature as
> it is specific to d-i.
Here we go, udeb-support branch in:
https://salsa.debian.org/kibi/open-iscsi
Tested successfully on amd64:
- produces t
On Sat, 2021-05-15 at 17:37 +0200, Cyril Brulebois wrote:
> Ritesh Raj Sarraf (2021-05-15):
> > Yes. That scsi-modules support bites back now. I just forgot about
> > it
> > completely. My intent was to not duplicate another architecture
> > list
> in
> > d/rules, and in trying to simplify things,
Ritesh Raj Sarraf (2021-05-15):
> Yes. That scsi-modules support bites back now. I just forgot about it
> completely. My intent was to not duplicate another architecture list in
> d/rules, and in trying to simplify things, it has just fallen apart
> with this old oddity of support on armel.
I'm h
On Sat, 2021-05-15 at 16:30 +0200, Cyril Brulebois wrote:
> It's just scsi-modules that's not available on armel apparently.
>
> As far as I know, armel is in “maintenance mode” anyway, trying not
> to
> lose support for old devices. I wouldn't worry if an optional
> component
> like open-iscsi(-u
Hi,
(cc += debian-arm@)
Ritesh Raj Sarraf (2021-05-15):
> While this bug is now in fixed status with the recent upload of open-
> iscsi version 2.1.3-4, there's still some other issue about the udeb
> being reported on the tracker package.
>
> In particular, it metions:
> open-iscsi-udeb/armel
Hi Cyril,
While this bug is now in fixed status with the recent upload of open-
iscsi version 2.1.3-4, there's still some other issue about the udeb
being reported on the tracker package.
In particular, it metions:
open-iscsi-udeb/armel has unsatisfiable dependency
I see now difference in the g
Hi,
Ritesh Raj Sarraf (2021-04-30):
> The upload I prepped failed on some of the architectures.
> https://buildd.debian.org/status/logs.php?pkg=open-iscsi&ver=2.1.3-3
It's lacking a push to the Git repository (git fetch didn't get anything
new from a few days ago).
> In d/control, there is:
>
On Fri, 2021-04-30 at 21:20 +0530, Ritesh Raj Sarraf wrote:
>
> How would you like to see this fixed Cyril ?
>
> The easiest option, if d-i supports, would be to extend architecture
> list to: `linux-any`, keeping it in line with what the actual open-
> iscsi package supports.
Here's what I've d
The upload I prepped failed on some of the architectures.
https://buildd.debian.org/status/logs.php?pkg=open-iscsi&ver=2.1.3-3
In d/control, there is:
```
Package: open-iscsi-udeb
# Note: the (virtual) udeb package scsi-modules (provided by different
# linux kernel udebs) must exist for the
On Thu, 2021-04-29 at 08:28 +0200, Cyril Brulebois wrote:
> OK, it's slighty different from the haveged package I mentioned that
> you
> could have taken as an example… but I think it should serve our
> purpose
> in a suitable fashion, so feel free to go ahead, thanks!
>
In the interest of the li
Hi,
Ritesh Raj Sarraf (2021-04-28):
> Please review the attached patch. I build tested locally and the
> results are below. If this looks good to you, then I'll prepare an
> upload and ask the release team for an unblock.
OK, it's slighty different from the haveged package I mentioned that you
c
Hi Cyril,
On Wed, 2021-04-28 at 17:51 +0200, Cyril Brulebois wrote:
> >
> > Why not just drop the dependency on udev and libopeniscsiusr
> entirely,
> > for the open-iscsi-udeb package ?
>
> This is not sufficient:
Please review the attached patch. I build tested locally and the
results are bel
Hi Ritesh,
Ritesh Raj Sarraf (2021-04-28):
> That's an explicit dependency that got added in the merge I reviewed
> for 2.1.2.
>
> Why not just drop the dependency on udev and libopeniscsiusr entirely,
> for the open-iscsi-udeb package ?
This is not sufficient:
--- a/debian/control
+++
Hi Cyril,
On Sun, 2021-04-25 at 22:02 +0200, Cyril Brulebois wrote:
> but it seems the experimental uploads weren't fetched for some reason
> (I only glanced at git, didn't check what happened on the archive
> side).
>
> Since the problem is about the dependency between the udeb and one of
> the
Control: found -1 2.1.2-1
Cyril Brulebois (2021-04-25):
> I'm currently chasing other blocking bugs for the installer, but I'll
> add this bug to the list, and try to get back to it later.
A quick debsnap shows at least those versions are affected:
2.1.2-1
2.1.2-2
2.1.3-1
2.1.3-2
but i
Package: open-iscsi-udeb
Version: 2.1.3-2
Severity: serious
Justification: not installable
X-Debbugs-Cc: debian-boot@lists.debian.org
Hi,
The udeb isn't installable at the moment, due to:
Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1i), libisns-udeb,
libkmod2-udeb (>= 28), libm
So as it seems that I am asked to re-write my question to be more of an
open question, let me state it this way.
Can someone please show me the proper way to allow D-I to accept standard
DEB packages into the core build of D-I?
If this is not possible, then it seems that I will have to convert al
On Wed, Oct 16, 2019 at 03:38:35PM -0400, Lonnie Cumberland wrote:
> On Wed, Oct 16, 2019 at 3:16 PM Geert Stappers wrote:
> > On Wed, Oct 16, 2019 at 01:08:54PM -0400, Lonnie Cumberland wrote:
> > > Greetings All,
> > >
> > > I have been able to build D-I on Buster with no problems and now want to
I really just trying to learn more about how the Debian Installer works so
that perhaps I can contribute in the near future as well as learning how to
achieve the goals that I am trying to accomplish by being able to simple
add a package to learn what it takes to achieve that objective. My
estimati
On Wed, Oct 16, 2019 at 01:08:54PM -0400, Lonnie Cumberland wrote:
> Greetings All,
>
> I have been able to build D-I on Buster with no problems and now want to
> add a package to test, but am getting a lot of dependency issues:
>
> --
... 33 lines ...
> E: Unable to
Greetings All,
I have been able to build D-I on Buster with no problems and now want to
add a package to test, but am getting a lot of dependency issues:
--
The following packages have unmet dependencies:
Depends: libcurl3 (>= 7.16.2) but it is not installable
Hi,
Martin Michlmayr (2015-12-28):
> The following workaround works for me but I'm not sure if it's the
> right approach.
>
> diff --git a/build/util/pkg-list b/build/util/pkg-list
> index 29c56c9..6ef74b8 100755
> --- a/build/util/pkg-list
> +++ b/build/util/pkg-list
> @@ -101,9 +101,13 @@ sub
I forgot to mention that I called pkg-list like this:
./util/pkg-list netboot/network-console "" di 2.6 "orion5x" 4.3.0-1-orion5x
--
Martin Michlmayr
http://www.cyrius.com/
Package: debian-installer
Version: 20151024
pkg-lists/netboot/armel.cfg contains:
usb-serial-modules-${kernel:Version} ?
so usb-serial-modules is included when available.
Now put the following line in
pkg-lists/netboot/network-console/armel/orion5x.cfg
usb-serial-modules-${kernel:Version} -
to ex
Hello,
Christian Perrier, le Tue 19 May 2009 07:32:54 +0200, a écrit :
> Daily builds that include brltty-udeb are failing since about 2 days:
>
> The following packages have unmet dependencies:
> brltty-udeb: Depends: libsm6 but it is not installable
>Depends: libx11-6 but it i
Daily builds that include brltty-udeb are failing since about 2 days:
The following packages have unmet dependencies:
brltty-udeb: Depends: libsm6 but it is not installable
Depends: libx11-6 but it is not installable
Depends: libxaw7 but it is not installable
Jérémy Bobbio <[EMAIL PROTECTED]> writes:
> Just an idea after having reported this bug: would it be possible to add
> a lintian check to see if udebs do not depends on non-udebs packages?
Yes. It would be nice.
> Should I speak to lintian maintainers about it, or do you already see
> any reason
Hi!
On Tue, Sep 04, 2007 at 12:08:46AM +0200, Jérémy Bobbio wrote:
> Package: brltty-udeb
> Version: 3.8-6
> Severity: serious
> Tags: patch, d-i
> [...]
> The udeb created by brltty depends on the libgpmg1 package which is not
> available in the debian-installer environment.
Just an idea after
28 matches
Mail list logo
