ported.
3. Install mplayer from the repository and run with: mplayer -ao sun
soundfile.ogg
Enjoy :-)
--
Robert Millan
ported.
3. Install mplayer from the repository and run with: mplayer -ao sun
soundfile.ogg
Enjoy :-)
--
Robert Millan
that this code was written by you:
El 16/08/15 a les 21:02, Olaf Buddenhagen ha escrit:
On Sun, Aug 16, 2015 at 01:09:59PM +0200, Robert Millan wrote:
* It includes code from other people under GPLv2;
- intrthread() is heavily based on intloop() from
hurd/libddekit/interrupt.c
I ha
that this code was written by you:
El 16/08/15 a les 21:02, Olaf Buddenhagen ha escrit:
On Sun, Aug 16, 2015 at 01:09:59PM +0200, Robert Millan wrote:
* It includes code from other people under GPLv2;
- intrthread() is heavily based on intloop() from
hurd/libddekit/interrupt.c
I ha
upt.c- mach_msg_type_t intr_type;
libddekit/interrupt.c- int line;
libddekit/interrupt.c:} mach_intr_notification_t;
Would you consider installing it in /usr/include/device/ for the sake of other
programs who also want to do funny things with interrupts on userspace? :-)
--
Robert Millan
upt.c- mach_msg_type_t intr_type;
libddekit/interrupt.c- int line;
libddekit/interrupt.c:} mach_intr_notification_t;
Would you consider installing it in /usr/include/device/ for the sake of other
programs who also want to do funny things with interrupts on userspace? :-)
--
Robert Millan
upt.c- mach_msg_type_t intr_type;
libddekit/interrupt.c- int line;
libddekit/interrupt.c:} mach_intr_notification_t;
Would you consider installing it in /usr/include/device/ for the sake of other
programs who also want to do funny things with interrupts on userspace? :-)
--
Robert Millan
upt.c- mach_msg_type_t intr_type;
libddekit/interrupt.c- int line;
libddekit/interrupt.c:} mach_intr_notification_t;
Would you consider installing it in /usr/include/device/ for the sake of other
programs who also want to do funny things with interrupts on userspace? :-)
--
Robert Millan
o people from University of Dresden. Given the DDE
heritage of the code, I'm not sure who's the author of intloop() routine, as it
is mostly Gnumach-aware code and seems unlikely to be part of DDE per se.
Do you recall where it came from?
Many thanks
--
Robert Millan
o people from University of Dresden. Given the DDE
heritage of the code, I'm not sure who's the author of intloop() routine, as it
is mostly Gnumach-aware code and seems unlikely to be part of DDE per se.
Do you recall where it came from?
Many thanks
--
Robert Millan
took care to use the same limits Rump namespace has, just to avoid accidental
cross-definition of a different value causing damage somewhere (e.g. overflows
or such).
--
Robert Millan
--- a/buildrump.sh/buildrump.sh
+++ b/buildrump.sh/buildrump.sh
@@ -1074,6 +1074,7 @@
*-gnu*)
EXTRA_RUMPCO
opyright-significant
though).
--
Robert Millan
--- /dev/null
+++ b/pci-userspace/src-gnu/Makefile
@@ -0,0 +1,21 @@
+RUMPTOP= ${TOPRUMP}
+
+RUMPCOMP_USER_SRCS.rumpdev_pci= pci_user-gnu.c experimentalUser.c
+RUMPCOMP_USER_PATH.rumpdev_pci:= ${.PARSEDIR}
+RUMPCOMP_USER_CPPFLAGS.rumpdev
Hi,
Here's the first patch of my port of Rump to GNU/Hurd. It includes the basic
system detection stuff.
--
Robert Millan
--- a/buildrump.sh/buildrump.sh
+++ b/buildrump.sh/buildrump.sh
@@ -993,6 +993,13 @@
cppdefines _LITTLE_ENDIAN \
&& appendvar RUMPKERN_UNDEF -U_
Hi,
Apparently this routine only wants the Rump version of when
building with Rump namespace, but it includes the header unconditionally.
This is usually harmless as almost everyone has , but GNU/Hurd
doesn't. So my patch just moves it into Rump protected space.
--
Robert Millan
not sure I follow. Please correct me if I missunderstood, but what I see is
that
the Makefile in libpci (buildrump.sh tree) is the one actually building and
linking of
OS-specific code in pci-userspace.
Therefore the Makefile in pci-userspace needs to pass along its requirements by
exporting
som
took care to use the same limits Rump namespace has, just to avoid accidental
cross-definition of a different value causing damage somewhere (e.g. overflows
or such).
--
Robert Millan
--- a/buildrump.sh/buildrump.sh
+++ b/buildrump.sh/buildrump.sh
@@ -1074,6 +1074,7 @@
*-gnu*)
EXTRA_RUMPCO
opyright-significant
though).
--
Robert Millan
--- /dev/null
+++ b/pci-userspace/src-gnu/Makefile
@@ -0,0 +1,21 @@
+RUMPTOP= ${TOPRUMP}
+
+RUMPCOMP_USER_SRCS.rumpdev_pci= pci_user-gnu.c experimentalUser.c
+RUMPCOMP_USER_PATH.rumpdev_pci:= ${.PARSEDIR}
+RUMPCOMP_USER_CPPFLAGS.rumpdev
Hi,
Apparently this routine only wants the Rump version of when
building with Rump namespace, but it includes the header unconditionally.
This is usually harmless as almost everyone has , but GNU/Hurd
doesn't. So my patch just moves it into Rump protected space.
--
Robert Millan
Hi,
Here's the first patch of my port of Rump to GNU/Hurd. It includes the basic
system detection stuff.
--
Robert Millan
--- a/buildrump.sh/buildrump.sh
+++ b/buildrump.sh/buildrump.sh
@@ -993,6 +993,13 @@
cppdefines _LITTLE_ENDIAN \
&& appendvar RUMPKERN_UNDEF -U_
On 16/08/15 13:20, Antti Kantee wrote:
> On 16/08/15 00:55, Robert Millan wrote:
>> Uhm yes, I think it could be useful to me. However based on your replies I
>> suspect I may be doing
>> something strange, or at least unusual.
>
> Ok send a patch for that
On 16/08/15 13:15, Antti Kantee wrote:
> On 16/08/15 11:12, Robert Millan wrote:
>>>> Currently the intrthread loop just checks the number of bytes read, but
>>>> a quick peek at the Linux source shows that /dev/uioX has a few failure
>>>> conditions. Att
On 16/08/15 13:11, Antti Kantee wrote:
> On 16/08/15 00:44, Robert Millan wrote:
>>
>> Hi,
>>
>> This patch enables pci-userspace Makefile to set LDFLAGS for libpci, for OS
>> ports that need extra libraries (surprise, surprise! ;-))
>
> Hmm, I'm not
On 16/08/15 13:08, Antti Kantee wrote:
> On 16/08/15 00:40, Robert Millan wrote:
>>
>> Hi,
>>
>> Currently the intrthread loop just checks the number of bytes read, but
>> a quick peek at the Linux source shows that /dev/uioX has a few failure
>> conditions.
) function in this code is being quite
useful. Also note
the replacement of O_NDELAY and O_CLOEXEC by hardcoded numbers, where a similar
translation facility
would be useful too.
Am I doing something completely wrong here? Does this look like the right way
of using
rump_sys_{open,ioctl,etc}?
Hi,
This patch enables pci-userspace Makefile to set LDFLAGS for libpci, for OS
ports that need extra libraries (surprise, surprise! ;-))
--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
Hi,
Currently the intrthread loop just checks the number of bytes read, but
a quick peek at the Linux source shows that /dev/uioX has a few failure
conditions. Attached patch tries to do a better job at detecting and
reporting them.
--
Robert Millan
Index: rumpkernel-0~20150715/pci-userspace
Hi,
The calls made by rumpuser_clock_sleep() have a few error conditions (see my
previous mail). IMHO it would be better to inform about them rather than just
assert.
--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/sys/rump/librump/rumpkern/intr.c
the result of clock_nanosleep() to comply with
expectations, hence
handle EINTR properly as with the rest of the functions in the routine.
--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/lib/librumpuser/rumpuser.c
out of sync if/when NetBSD
adds new errnos.
Since other host code using rump could easily need the same thing, why not just
put this in
librumpuser like its rumpuser__errtrans() counterpart? Would make life easier
for everyone
in this situation IMHO.
--
Robert Millan
Hi Antti,
El 11/08/15 a les 01:17, Antti Kantee ha escrit:
On 10/08/15 21:26, Robert Millan wrote:
If you want more, look at syscall compat (full, automated translation)
Please forgive my ignorance, but I'm not sure what you mean by syscall
compat. Could
you point me to some document a
Hi Antti,
El 10/08/15 a les 09:20, Antti Kantee ha escrit:
On 08/08/15 19:38, Robert Millan wrote:
Hi!
I found myself in need of rumpuser__errtrans_rump2host() to properly
transmit
errors back to the host upper layer after it requested rump services
through
rump_sys_* syscalls.
Can you
Hi!
I found myself in need of rumpuser__errtrans_rump2host() to properly transmit
errors back to the host upper layer after it requested rump services through
rump_sys_* syscalls.
So I just implemented it. Here you are :-)
--
Robert Millan
diff --git a/lib/librumpuser/rumpuser_component.c b
Attached.
Thanks
El 14/06/15 a les 19:07, Antti Kantee ha escrit:
On 14/06/15 13:57, Robert Millan wrote:
The print still doesn't match the call. How do you know at that
abstraction level that initiopl() will exactly "raise I/O privilege
level"?
Well that's what "
box due to shared IRQs.
I suspect it might be a Virtualbox bug, as I couldn't reproduce the problem
anywhere other than Vbox, and I didn't
investigate further as I found a simple workaround (attached, maybe someone
will find it useful).
--
Robert Millan
Index: linux-3.2.60/drivers/u
ached in my Bachelor Thesis, c.f. [1]
for details.
[1] http://upcommons.upc.edu/pfc/bitstream/2099.1/25316/1/104462.pdf, page 41
--
Robert Millan
El 14/06/15 a les 14:05, Antti Kantee ha escrit:
On 14/06/15 11:54, Robert Millan wrote:
Thanks Antti. Here's the new patchset.
Almost there. Still small nits:
#ifdef RUMP_PCI_IOSPACE
-pba.pba_flags |= PCI_FLAGS_IO_OKAY;
+#ifdef rumpcomp_pci_initiopl
+
box due to shared IRQs.
I suspect it might be a Virtualbox bug, as I couldn't reproduce the problem
anywhere other than Vbox, and I didn't
investigate further as I found a simple workaround (attached, maybe someone
will find it useful).
--
Robert Millan
Index: linux-3.2.60/drivers/u
ached in my Bachelor Thesis, c.f. [1]
for details.
[1] http://upcommons.upc.edu/pfc/bitstream/2099.1/25316/1/104462.pdf, page 41
--
Robert Millan
d there or not.
Does someone know?
--
Robert Millan
Index: rumpkernel-0~20150607/buildrump.sh/src/sys/dev/hdaudio/hdaudiodevs
===
--- rumpkernel-0~20150607.orig/buildrump.sh/src/sys/dev/hdaudio/hdaudiodevs 2015-06-07 17:04:54.0
d there or not.
Does someone know?
--
Robert Millan
Thanks Antti. Here's the new patchset.
Best regards
El 13/06/15 a les 19:37, Antti Kantee ha escrit:
On 12/06/15 21:25, Robert Millan wrote:
El 08/06/15 a les 07:53, Antti Kantee ha escrit:
>> +int rumpcomp_pci_init(int, int *);
>
> Now that rumpcomp_userfeatures_pci.h i
you should not return
the return value of iopl(), but rather the translated errno.
Are there any facilities and/or standard way of doing this? Or should I just
use an ad-hoc switch/case with possible iopl() errnos?
Thanks
--
Robert Millan
ne, rd/mult, wr/inv ok
I think those unfamiliar with Rump and/or NetBSD will find the extra
information useful.
--
Robert Millan
Hi!
El 24/05/15 a les 15:58, Antti Kantee ha escrit:
On 24/05/15 13:33, Robert Millan wrote:
Hi
Please consider attached patch:
Add a few symlinks which are commonly expected by applications
/dev/audio-> audio0
/dev/sound-> sound0
/dev/audioctl ->
El 06/06/15 a les 22:34, Robert Millan ha escrit:
El 31/05/15 a les 13:34, Robert Millan ha escrit:
Okay. I assume you'll want to make code dependencies time-consistent, so here's
my first patch to add
the rumpcomp_pci_init() interface in pci_user.h.
I'll send a followup fo
El 31/05/15 a les 13:34, Robert Millan ha escrit:
Okay. I assume you'll want to make code dependencies time-consistent, so here's
my first patch to add
the rumpcomp_pci_init() interface in pci_user.h.
I'll send a followup for pci-userspace, then back to libpci.
Second patc
Hi,
Please forgive my ignorance on NetBSD make flags; does anyone know how to make
the Rump build
system enable them?
E.g.
.if ${RUMP_PCI_IOSPACE:Uno} == "yes"
CPPFLAGS+=-DRUMP_PCI_IOSPACE
.endif
--
Robert Millan
Hi,
Sorry for the delay in replying...
On 31/07/14 23:47, Antti Kantee wrote:
On 31/07/14 20:05, Robert Millan wrote:
Now, since your rumpuser_io_init() is really only used by pci-userspace code,
we don't have to make
>>> it part of the main rumpuser interface. You can add
Hi!
El 24/05/15 a les 16:23, Antti Kantee ha escrit:
On 24/05/15 14:00, Robert Millan wrote:
Hi!
Please consider attached patches:
(rump) Implement bus_dmamem_free()
(pci-userspace) Implement rumpcomp_pci_free(), used by
bus_dmamem_free() in RUMP
Ok. Can you submit the second
ture.
Here's a new (tested) patch.
Many thanks
--
Robert Millan
diff --git a/sys/dev/pci/auich.c b/sys/dev/pci/auich.c
index 481ed16..ae1662f 100644
--- a/sys/dev/pci/auich.c
+++ b/sys/dev/pci/auich.c
@@ -232,6 +232,8 @@ struct auich_softc {
struct audio_format sc_modem_formats[AUICH_MODEM
x27;d rather see the specific code in the specific
device driver that depends on that before thinking about it more.
Well, so far I haven't found any evidence that my other fixes for
hardware-related timing problems
require this. I guess if problems arise we can revisit the matter :)
--
Robert Millan
El 24/05/15 a les 16:15, Antti Kantee ha escrit:
Robert,
On 24/05/15 14:08, Robert Millan wrote:
Can you briefly explain what problem this patch is intending to solve?
I'm not sure I understand why you want it.
I'm actually not sure. When I wrote this, I was chasing a race condit
And this one is kern/49927
El 24/05/15 a les 15:52, Robert Millan ha escrit:
Hi!
Please consider attached patch:
Avoid division by zero
As wait_us is calculated by polling an I/O register, it is possible
in certain environments (e.g. emulated hardware) that its value is
ommit your patches in a few days if nobody else
takes action.
Gladly. This one is kern/49926 now.
Thanks
--
Robert Millan
heduler() from
somewhere else then. Any
suggestion?
--
Robert Millan
Hi!
Please consider attached patches:
(rump) Implement bus_dmamem_free()
(pci-userspace) Implement rumpcomp_pci_free(), used by
bus_dmamem_free() in RUMP
Thanks
--
Robert Millan
diff --git a/sys/rump/dev/lib/libpci/pci_user.h b/sys/rump/dev/lib/libpci/pci_user.h
index
division by zero in such situation.
Thanks
--
Robert Millan
diff --git a/sys/dev/pci/auich.c b/sys/dev/pci/auich.c
index b2adad1..6a52800 100644
--- a/sys/dev/pci/auich.c
+++ b/sys/dev/pci/auich.c
@@ -1723,6 +1723,13 @@ auich_calibrate(struct auich_softc *sc)
rnd_add_data(NULL, &wai
Thanks
--
Robert Millan
diff --git a/sys/dev/pci/auich.c b/sys/dev/pci/auich.c
index 3038091..b2adad1 100644
--- a/sys/dev/pci/auich.c
+++ b/sys/dev/pci/auich.c
@@ -789,6 +789,19 @@ auich_read_codec(void *v, uint8_t reg, uint16_t *val)
ICH_CAS + sc->sc_modem_offset) & 1;
might need #ifdef __linux__ wrap, but I'm not sure as the
interface is quite POSIXy. Anyone feel like testing?
Thanks
--
Robert Millan
diff --git a/lib/librumpuser/rumpuser.c b/lib/librumpuser/rumpuser.c
index a1e9068..0b5154c 100644
--- a/lib/librumpuser/rumpuser.c
+++ b/lib/librumpuser/rumpu
Hi
Please consider attached patch:
Add a few symlinks which are commonly expected by applications
/dev/audio-> audio0
/dev/sound-> sound0
/dev/audioctl -> audioctl0
/dev/mixer-> mixer0
Thanks!
--
Robert Millan
diff --git a/sys/rump/dev/
El 16/02/15 a les 14:53, Antti Kantee ha escrit:
On 15/02/15 21:24, Robert Millan wrote:
It occurred to me that there are a number of theses featuring rump
kernels, so I started a section on the wiki for that. Can you add yours
here:
http://wiki.rumpkernel.org/Info%3A-Publications-and-Talks
El 15/02/15 a les 19:12, Antti Kantee ha escrit:
> On 15/02/15 14:52, Robert Millan wrote:
>> Development has been performed as part of my final year Computer Engineering
>> project, you can see final report for details (includes a dissertation on
>> motivation, experimenta
ils (includes a dissertation on
motivation, experimental analysis of results, conclusions, etc):
https://mega.co.nz/#!mxQUFQqL!RwR961KrzBQSPH7h3XgoEEiwCK79EbYrbDVXM8WeUSg
> Looking forward to your patches!
:)
--
Robert Millan
-
$ sudo rumposs.sh mplayer audiofile.flac
--
Robert Millan
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub fo
On 31/07/14 18:00, Antti Kantee wrote:
> On 31/07/14 15:25, Robert Millan wrote:
>> Hi,
>>
>> Please consider this patch. It implements PCI I/O space on Linux by using
>> iopl()
>> to enable blanket I/O permissions.
>
> Hi Robert,
>
> Almost perf
Hi,
Please consider this patch. It implements PCI I/O space on Linux by using iopl()
to enable blanket I/O permissions.
It does also fix a small typo while at it ;-)
Regards
--
Robert Millan
diff --git a/lib/librumpuser/rumpuser.c b/lib/librumpuser/rumpuser.c
index b78cec3..7c3b2e5 100644
some reason, it'd be very useful for me to know in advance. I'm
not very
familiar with USB programming, so in case there's a showstopper it'd probably
take me a
while to notice .
Many thanks!
--
Robert Millan
--
On 08/06/14 00:00, Cyril Brulebois wrote:
Robert Millan (2014-06-07):
>On 02/06/14 20:13, Emilio Pozuelo Monfort wrote:
> >May I ask what was broken on gdm3 and gnome-shell to have caused all
> >these removals?
>
>Long-standing RC bugs in GDM3 [1], and your choice
On 08/06/14 00:00, Cyril Brulebois wrote:
Robert Millan (2014-06-07):
>On 02/06/14 20:13, Emilio Pozuelo Monfort wrote:
> >May I ask what was broken on gdm3 and gnome-shell to have caused all
> >these removals?
>
>Long-standing RC bugs in GDM3 [1], and your choice
ome-core still achieves its purpose without
gnome-shell.
I think that's something for the gnome-core maintainers to figure out.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ome-core still achieves its purpose without
gnome-shell.
I think that's something for the gnome-core maintainers to figure out.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ome-core still achieves its purpose without
gnome-shell.
I think that's something for the gnome-core maintainers to figure out.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
ome-core still achieves its purpose without
gnome-shell.
I think that's something for the gnome-core maintainers to figure out.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
ific or cpu-specific packages.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53938a0d.4030...@debian.org
ific or cpu-specific packages.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53938a0d.4030...@debian.org
tches.
Alternatively, just ignore this mess and stop bothering us.
[1]
#602724
#601106
#612157
#733546
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debi
tches.
Alternatively, just ignore this mess and stop bothering us.
[1]
#602724
#601106
#612157
#733546
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debi
;s already been stablished that GDM3 is unportable, and why. If you can't
find a way to make gnome-terminal work without GDM3, then please make it
Linux-only until you can.
I'm afraid you can't rely on porter teams to fix this. gnome-terminal dependency
on GDM3 has nothing to do with port
;s already been stablished that GDM3 is unportable, and why. If you can't
find a way to make gnome-terminal work without GDM3, then please make it
Linux-only until you can.
I'm afraid you can't rely on porter teams to fix this. gnome-terminal dependency
on GDM3 has nothing to do with port
;s already been stablished that GDM3 is unportable, and why. If you can't
find a way to make gnome-terminal work without GDM3, then please make it
Linux-only until you can.
I'm afraid you can't rely on porter teams to fix this. gnome-terminal dependency
on GDM3 has nothing to do with port
;s already been stablished that GDM3 is unportable, and why. If you can't
find a way to make gnome-terminal work without GDM3, then please make it
Linux-only until you can.
I'm afraid you can't rely on porter teams to fix this. gnome-terminal dependency
on GDM3 has nothing to do with port
bug=735023#10
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
are being satisfied when it comes to GNOME on non-Linux ports.
I take note that's no longer the case and will drop the list from CC in
future mails regarding this issue.
Apologies for any inconvenience this missunderstanding may have caused.
--
Robert Millan
--
To UNSUBSCRIBE, email to debia
are being satisfied when it comes to GNOME on non-Linux ports.
I take note that's no longer the case and will drop the list from CC in
future mails regarding this issue.
Apologies for any inconvenience this missunderstanding may have caused.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-
bug=735023#10
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
are being satisfied when it comes to GNOME on non-Linux ports.
I take note that's no longer the case and will drop the list from CC in
future mails regarding this issue.
Apologies for any inconvenience this missunderstanding may have caused.
--
Robert Millan
--
To UNSUBSCRIBE, email to debia
are being satisfied when it comes to GNOME on non-Linux ports.
I take note that's no longer the case and will drop the list from CC in
future mails regarding this issue.
Apologies for any inconvenience this missunderstanding may have caused.
--
Robert Millan
--
To UNSUBSCRIBE, email to d
are being satisfied when it comes to GNOME on non-Linux ports.
I take note that's no longer the case and will drop the list from CC in
future mails regarding this issue.
Apologies for any inconvenience this missunderstanding may have caused.
--
Robert Millan
--
To UNSUBSCRIBE, email to de
bug=735023#10
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538a079e.8050...@debian.org
bug=735023#10
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538a079e.8050...@debian.org
bug=735023#10
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538a079e.8050...@debian.org
hat the resulting package will be usable?
Unfortunately I cannot answer them myself, because I'm not familiar with GNOME
development procedures, nor with the implied commitments that come with them.
It would be very nice if the GNOME maintainers can cast some light on this.
Thanks in advance,
-
hat the resulting package will be usable?
Unfortunately I cannot answer them myself, because I'm not familiar with GNOME
development procedures, nor with the implied commitments that come with them.
It would be very nice if the GNOME maintainers can cast some light on this.
Thanks in advance,
-
hat the resulting package will be usable?
Unfortunately I cannot answer them myself, because I'm not familiar with GNOME
development procedures, nor with the implied commitments that come with them.
It would be very nice if the GNOME maintainers can cast some light on this.
Thanks in advance,
-
hat the resulting package will be usable?
Unfortunately I cannot answer them myself, because I'm not familiar with GNOME
development procedures, nor with the implied commitments that come with them.
It would be very nice if the GNOME maintainers can cast some light on this.
Thanks in advance,
-
hat the resulting package will be usable?
Unfortunately I cannot answer them myself, because I'm not familiar with GNOME
development procedures, nor with the implied commitments that come with them.
It would be very nice if the GNOME maintainers can cast some light on this.
Thanks in advance,
-
On 31/05/14 17:51, Andreas Henriksson wrote:
Maybe you should try to spend 2 seconds on trying to figure it out
(ie. by searching the package changelog) before posting in the future.
Why?
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
On 31/05/14 17:51, Andreas Henriksson wrote:
Maybe you should try to spend 2 seconds on trying to figure it out
(ie. by searching the package changelog) before posting in the future.
Why?
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
On 31/05/14 17:51, Andreas Henriksson wrote:
Maybe you should try to spend 2 seconds on trying to figure it out
(ie. by searching the package changelog) before posting in the future.
Why?
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of
On 31/05/14 17:51, Andreas Henriksson wrote:
Maybe you should try to spend 2 seconds on trying to figure it out
(ie. by searching the package changelog) before posting in the future.
Why?
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of
101 - 200 of 17123 matches
Mail list logo
