On 2025-02-11 14:37, Yuqian Yang wrote:
This patch still uses a PATH_MAX stuck on Hurd. But it at least
can unblock your other works.
PATH_MAX stub.
Thanks.
--
Yuqian Yang
Hello,
On 2025-02-08 09:05, Sam Hartman wrote:
* I work with the porter and review the patches.
Thanks.
I have put 2 patches in attachment. `hurd-fix.patch` is the
real patch for fixing problems on Hurd. You have to put this
to `debian/patches` manually and change the `series`.
`hurd
1029097-d...@bugs.debian.org
Cc: debian-h...@lists.debian.org
Subject:Re: Bug#1029097: PAM HURD patches
Date: Fri, 07 Feb 2025 18:05:05 -0700 (08.02.2025 02:05:05)
control: tags -1 wontfix
Hi.
I still have not received an answer to my questions.
Also, the patch as written would not be suf
These are generic, relatively independent patches from the AArch64
branch. I've done a quick build for i386-gnu and things still seem to
build, but please test!
Sergey
El martes 20 de junio de 2023, Samuel Thibault escribió:
> Almudena Garcia, le lun. 19 juin 2023 18:35:51 +, a ecrit:
> > phystokv will doesn't solve fully the problem, because the lapic address is
> > out of the range allowed by this function.
>
> Ah, right.
>
> > Currently, we are using
Almudena Garcia, le lun. 19 juin 2023 18:35:51 +, a ecrit:
> phystokv will doesn't solve fully the problem, because the lapic address is
> out of the range allowed by this function.
Ah, right.
> Currently, we are using paging to map every ACPI table which we need to
> access (to get a virtu
Hi Luca,
On 20/6/23 05:40, l...@orpolo.org wrote:
> and at this stage the lapic pointer is not yet initialized:
>
> (gdb) p lapic
> $4 = (volatile ApicLocalUnit *) 0x0
> (gdb) x &lapic
> 0xc109bc6c : 0x
>
> I guess so far this worked because the address 0 was mapped, and now it
> isn't
Maybe add a little conditional in the assembly code (return 0 if lapic is 0,
using cmp and je) could fix the problem in a simpler way
El lunes 19 de junio de 2023, l...@orpolo.org escribió:
> Il 19/06/23 20:35, Almudena Garcia ha scritto:
> > But the code which starts the secondary cpus is so muc
Il 19/06/23 21:40, l...@orpolo.org ha scritto:
and at this stage the lapic pointer is not yet initialized:
(gdb) p lapic
$4 = (volatile ApicLocalUnit *) 0x0
(gdb) x &lapic
0xc109bc6c : 0x
I guess so far this worked because the address 0 was mapped, and now it
isn't.
I'm not sure w
Il 19/06/23 20:35, Almudena Garcia ha scritto:
But the code which starts the secondary cpus is so much later than the crash.
Then, the crash could be produced by the reading of ACPI tables, which are
supposed to be in a certain memory region, defined by a physical address.
phystokv will doesn'
But the code which starts the secondary cpus is so much later than the crash.
Then, the crash could be produced by the reading of ACPI tables, which are
supposed to be in a certain memory region, defined by a physical address.
phystokv will doesn't solve fully the problem, because the lapic add
Hi,
Il 18/06/23 22:52, Samuel Thibault ha scritto:
Hello,
Damien Zammit, le dim. 18 juin 2023 00:48:15 +, a ecrit:
Almu and I discovered that the following commit breaks --enable-apic
--enable-ncpus= >1 --disable-linux-groups
* d972c01c pmap: only map lower BIOS memory 1:1 when using
Hello,
Damien Zammit, le dim. 18 juin 2023 00:48:15 +, a ecrit:
> Almu and I discovered that the following commit breaks --enable-apic
> --enable-ncpus= >1 --disable-linux-groups
>
> * d972c01c pmap: only map lower BIOS memory 1:1 when using Linux drivers
>
> I believe the ACPI tables nee
Hi,
Almu and I discovered that the following commit breaks --enable-apic
--enable-ncpus= >1 --disable-linux-groups
* d972c01c pmap: only map lower BIOS memory 1:1 when using Linux drivers
I believe the ACPI tables need temporary low memory mapping to access them.
Also, the commit:
* 54a4ca2
On Tue, 2 May 2023, Sergey Bugaev via Libc-alpha wrote:
> It would also probably make sense to mention my other changes, of
> which there have been many, in the NEWS (would a simple "many fixes
> and improvements in the Hurd port" suffice?)
That may well be an appropriate way to describe them (if
On Tue, 2 May 2023, Samuel Thibault via Libc-alpha wrote:
> Joseph Myers, le mar. 02 mai 2023 14:03:16 +, a ecrit:
> > On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote:
> >
> > > If these patches are pushed, it should be possible for anyone to build
> >
Joseph Myers, le mar. 02 mai 2023 14:03:16 +, a ecrit:
> On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote:
>
> > If these patches are pushed, it should be possible for anyone to build
> > x86_64-gnu glibc just out of Git master, without having to dig through
&g
Hello,
On Tue, May 2, 2023 at 5:03 PM Joseph Myers wrote:
> On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote:
>
> > If these patches are pushed, it should be possible for anyone to build
> > x86_64-gnu glibc just out of Git master, without having to dig through
&g
On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote:
> If these patches are pushed, it should be possible for anyone to build
> x86_64-gnu glibc just out of Git master, without having to dig through
> the mailing list archive for uncommited patches.
In that case I think there sh
These are the patches that I have locally that have not (yet) been
pushed. Most of them I have already sent previously, but have made
changes to since then. Please see the notes on individual patches.
I'm putting "v3" on the whole series because some of the patches here
have alrea
Hello,
Sergey Bugaev, le mer. 25 janv. 2023 10:48:35 +0300, a ecrit:
> > https://darnassus.sceen.net/~hurd-web/toolchain/cross-gnu/
>
> I must have already asked this before, but: how do I modify the wiki?
> Do I just send patches to bug-hurd? Is
You can, yes.
> http://gi
rresponding wiki page where it belongs,
>>
>> ./toolchain/cross-gnu.mdwn
>>
>> https://darnassus.sceen.net/~hurd-web/toolchain/cross-gnu/
>
>I must have already asked this before, but: how do I modify the wiki?
>Do I just send patches to bug-hurd? Is
I usually do that
&g
en.net/~hurd-web/toolchain/cross-gnu/
I must have already asked this before, but: how do I modify the wiki?
Do I just send patches to bug-hurd? Is
http://git.savannah.gnu.org/cgit/hurd/web.git the wiki's repo, or is
it https://darnassus.sceen.net/cgit/hurd-web.git, or something else?
Other th
tall| 1 +
> debian/patches/ahcisata-atapi.diff | 26 ---
> debian/patches/ahcisata-rump.diff | 108 +--
> debian/patches/ata-rump.diff | 290 +++++
> debian/patches/piixide-rump.diff | 115 +---
> debian/patches/series |
With this commit, rumpdisk needs to be build with "rumpdev_ahcisata
rumpdev_piixide rumpdev_ata".
---
debian/librumpdev-disk-dev.install | 3 +
debian/librumpdev-disk0.install| 1 +
debian/patches/ahcisata-atapi.diff | 26 ---
debian/patches/ahcisata-rump.diff | 108 +
Hi Samuel,
Thank you for reviewing my patches.
I want to let you know what I have ready for review next,
as I have 4 patch sets in the pipeline:
The network routing is completed, (see [PATCH v3 1+2]).
(I did not use inet_ntop because inet_ntoa is also thread safe)
Machdev race condition in
These patches are needed for newer librump (>= 9.99).
See my previous thread for details on how to configure grub.
Cheers,
Damien
On Sun, Oct 31, 2021 at 8:44 PM Svante Signell wrote:
> One alternative to the path_max.diff patch is to simply do:
> #ifndef PATH_MAX
> #define PATH_MAX 4096
> #endif
> in xf86drm.c. This is a patch that upstream would accept more easily than the
> proposed one, but is not very Hurdish.
>
> WDYT?
Hello,
After the patches sent to the libdrm package in #909436 was removed with version
2.4.103-2 due to bug #975658 causing problems with an "Invalid read after the
end of block in xf86drm.c" a year ago nothing happened. I've now taken up the
patches again, and try to solve th
On 27.4.2021 2.04, Svante Signell wrote:
On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote:
Hello Svante,
For information, your patch got dropped because of #975658
Yes I know since a long time. And you did not care or anybody else
either. So why bother... Why spend time on worthless i
Svante Signell, le mar. 27 avril 2021 01:04:30 +0200, a ecrit:
> On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote:
> > For information, your patch got dropped because of #975658
>
> Yes I know since a long time.
Ok, I hadn't seen it.
> And you did not care or anybody else either.
Well,
On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote:
> Hello Svante,
>
> For information, your patch got dropped because of #975658
Yes I know since a long time. And you did not care or anybody else
either. So why bother... Why spend time on worthless issues?
> It seems to have a few build issues on some archs:
>
> https://buildd.debian.org/status/package.php?p=lwip
Ooops! a new line in my TODO.
Samuel Thibault, le sam. 10 août 2019 00:48:04 +0200, a ecrit:
> Joan Lledó, le sam. 22 juin 2019 11:50:57 +0200, a ecrit:
> > I updated some patches for the lwip debian package, mostly bug-fixing,
> > but I also had to add a new patch to implement a new function required
> >
As a curiosity: How can I enable lwip as default netstack in Debian
GNU/Hurd?
El sáb., 10 ago. 2019 a las 0:48, Samuel Thibault ()
escribió:
> Hello,
>
> Joan Lledó, le sam. 22 juin 2019 11:50:57 +0200, a ecrit:
> > I updated some patches for the lwip debian package, mostly bug-
Hello,
Joan Lledó, le sam. 22 juin 2019 11:50:57 +0200, a ecrit:
> I updated some patches for the lwip debian package, mostly bug-fixing,
> but I also had to add a new patch to implement a new function required
> for the translator [1].
I have applied them in the debian repo and up
/2019-06/msg00010.html
Missatge de Joan Lledó del dia ds., 22 de
juny 2019 a les 11:51:
>
> Hi,
>
> I updated some patches for the lwip debian package, mostly bug-fixing,
> but I also had to add a new patch to implement a new function required
> for the translator [1].
>
&
* debian/patches/max_sockets:
* Update required after making changes in debian/patches/port
* debian/patches/patch9807:
* New patch: Add new function tcpip_callback_wait() in tcpip.c
* To call a function inside the tcpip thread and wait
for it to return
* debian/patches/port:
* Fix
Hi,
I updated some patches for the lwip debian package, mostly bug-fixing,
but I also had to add a new patch to implement a new function required
for the translator [1].
Regards.
---
[1] https://lists.gnu.org/archive/html/bug-hurd/2019-05/msg1.html
Hello,
Attached are some patches for the lwip translator. Mainly for bug-fixing and
error handling.
Svante Signell, le lun. 11 févr. 2019 12:10:21 +0100, a ecrit:
> WCONTINUED is not defined, I assume that WIFCONTINUED is not supported.
>
> From waitpid(2):
> WCONTINUED (since Linux 2.6.10)
>also return if a stopped child has been resumed by delivery of SIGCONT.
>
> @Samuel: more info?
git
Joan Lledó, le mar. 28 août 2018 23:14:32 +0200, a ecrit:
> Missatge de Samuel Thibault del dia dt., 28
> d’ag. 2018 a les 20:50:
> > Could you re-send it as a compressed file to make sure that
> > it doesn't get mangled?
>
> Sure, it's attached here.
Thanks! I have applied it.
Samuel
Missatge de Samuel Thibault del dia dt., 28
d’ag. 2018 a les 20:50:
> Could you re-send it as a compressed file to make sure that
> it doesn't get mangled?
Sure, it's attached here.
0001-Update-patches.tar.xz
Description: application/xz
Joan Lledó, le lun. 20 août 2018 12:39:42 +0200, a ecrit:
> > I agree about lwipopts.h. For cc.h I don't see how it is really related
> > with lwipopts.h, it all looks like making lwip use unix libc things
> > (*16_* and *32_* could use inttypes.h's PRI* macros btw)
>
> It depends on lwipopts.h b/
Missatge de Samuel Thibault del dia dv., 10
d’ag. 2018 a les 0:05:
> The removal of the unix library is worrying, however. Are they aware
> that some people are using it? If nobody complains, they won't know
> that it poses problem.
They probably don't know about our liblwip package, I missed t
.
Of course, here are the new patches.
Hello,
Joan Lledó, le mar. 07 août 2018 18:09:54 +0200, a ecrit:
> > So your autoconf effort and that effort could probably be merged?
>
> They recently removed their unix library from their lwip-contrib repo, and
> are wroking on replacing GNU Autotools for CMake[1], so I don't think they
> ar
Hello,
Joan Lledó, le mar. 07 août 2018 18:02:39 +0200, a ecrit:
> Here are some patches for the lwip translator. They solve minor problems I've
> found when working on our lwip library.
Thanks :)
But could you write the proper ChangeLog entries to explain not only why
the change bu
:Protect the socket list every time it's read
All but AUTOCONF: Converted to DOS format to mach lwip sources
All: Remove fuzziness
---
debian/patches/bug-36167 |8 +-
debian/patches/errno | 20 +-
debian/patches/max_sockets | 75 +-
debian/patches/poll|
Hi,
Attached is a patch to update our lwip library.
About autoconf:
> So your autoconf effort and that effort could probably be merged?
They recently removed their unix library from their lwip-contrib repo, and are
wroking on replacing GNU Autotools for CMake[1], so I don't think they are
i
Hello Hurd,
Here are some patches for the lwip translator. They solve minor problems I've
found when working on our lwip library.
Regards.
Hello,
Luca Weiss, le mar. 12 juin 2018 12:57:06 +0200, a ecrit:
> I needed the following patches to build hurd commit 679b58fa.
Applied, thanks!
Samuel
Hello,
I needed the following patches to build hurd commit 679b58fa.
All instances of "minor (", "major (", "makedev (" were prefixed with
"gnu_dev_" because of errors like
../libfshelp/libfshelp.so: undefined reference to `minor'
And I added two
so he dropped; no big deal.
>
> Yes it is a big deal. If somebody spends numerous (spare time, unpaid) hours
> porting gccgo to Hurd and that work is thrown away then this _is_ a big deal.
What else could he do? Really, please think about it.
No, he does not have (spare, unpaid) time to sp
ps://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=10084
>>>>
>>>> This is really a large step BACK:
>>>
>>> It's not a step back, it's just fixing something that is completely
>>> wrong.
>>
>> What is reall
what's currently there. If you don't see why
> that commit was a move forward concerning Debian, please do check its
> consequences and think about it.
??
> > As I wrote in that bug report, all needed patches are there. And as the bug
> > report says: gcc-8 (8-8-20180321
Svante Signell, on lun. 26 mars 2018 19:50:58 +0200, wrote:
> On Mon, 2018-03-26 at 19:42 +0200, Samuel Thibault wrote:
> > Svante Signell, on lun. 26 mars 2018 19:20:04 +0200, wrote:
> > >
> > > What is really wrong is that Matthias Klose removed the Hurd patches.
>
On Mon, 2018-03-26 at 19:42 +0200, Samuel Thibault wrote:
> Svante Signell, on lun. 26 mars 2018 19:20:04 +0200, wrote:
> >
> > What is really wrong is that Matthias Klose removed the Hurd patches.
>
> Sure, but see what he wrote in the changlog: he found the patches
>
sion=10084
> > >
> > > This is really a large step BACK:
> >
> > It's not a step back, it's just fixing something that is completely
> > wrong.
>
> What is really wrong is that Matthias Klose removed the Hurd patches.
Sure, but see what he
gt;>
>>> This is really a large step BACK:
>>
>> It's not a step back, it's just fixing something that is completely
>> wrong.
>
> What is really wrong is that Matthias Klose removed the Hurd patches. Adding
> them back is a piece of cake fo
t's not a step back, it's just fixing something that is completely
> wrong.
What is really wrong is that Matthias Klose removed the Hurd patches. Adding
them back is a piece of cake for you (or him), see #894080.
Next step is to send them to golang-dev for upstream adoption. gcc-patc
Svante Signell, on lun. 26 mars 2018 18:50:20 +0200, wrote:
> I just saw:
> https://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=10084
>
> This is really a large step BACK:
It's not a step back, it's just fixing something that is completely
wrong.
> Since you could issue that commit t
Hi Samuel,
I just saw:
https://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=10084
This is really a large step BACK: Since you could issue that commit to _disable_
gccgo for Hurd, what about committing to _enable_ gccgo for Hurd instead. I just
filed a bug for gcc-8 to build gccgo again
On Mon, 2018-03-12 at 14:44 +0100, Svante Signell wrote:
> On Mon, 2018-03-12 at 13:29 +0100, Svante Signell wrote:
>
>
> > The patches really changed are only four:
> > src_libgo_runtime.diff
> > src_libgo_go_go_build_syslist.go.diff
> > src_libgo_go_runt
On Mon, 2018-03-12 at 13:29 +0100, Svante Signell wrote:
> The patches really changed are only four:
> src_libgo_runtime.diff
> src_libgo_go_go_build_syslist.go.diff
> src_libgo_go_runtime.diff
> src_libgo_build.diff
Correction: five:
add-gnu-to-libgo-headers.diff
HI,
I'm about to submit patches for file record locking a third time. I have still
some comment/questions before doing that:
According to POSIX.1-2008:
Regular files:
F_SETLK can establish shared (or read) locks (F_RDLCK) or exclusive (or write)
locks (F_WRLCK), as well as to remove either
gt;> which generates a ChangeLog file from those.
>>
>
> OK, I think I see what you want.
>
Was that last patch in the desired format?
Would you like me to reformat the commit messages on the last ten rpctrace
patches and resubmit them?
agape
brent
On Wed, Nov 2, 2016 at 2:26 PM, Kalle Olavi Niemitalo wrote:
>
> Look at how the commit messages in hurd.git at Savannah (not at
> Debian) are formatted. "make dist" runs gitlog-to-changelog,
> which generates a ChangeLog file from those.
>
OK, I think I see what you want.
"Brent W. Baccala" writes:
> How do you submit changelog-style descriptions? They don't seem to be kept
> in ChangeLog...
Look at how the commit messages in hurd.git at Savannah (not at
Debian) are formatted. "make dist" runs gitlog-to-changelog,
which generates a ChangeLog file from those.
(
On Wed, Nov 2, 2016 at 3:10 AM, Justus Winter wrote:
>
> Cool. Two nitpicks: 1/ Instead of attaching patches, why don't you use
> git send-email. That is easier for everyone. 2/ The summary line of
> your patches is too long, try to keep it at ~60 chars or so, and we
&g
Hi!
"Brent W. Baccala" writes:
> I'm attaching two more patches to rpctrace that close bug 48863.
Cool. Two nitpicks: 1/ Instead of attaching patches, why don't you use
git send-email. That is easier for everyone. 2/ The summary line of
your patches is too long, try
Aloha -
I'm attaching two more patches to rpctrace that close bug 48863.
agape
brent
From 10a2a49e370ca55b6cea4cdc4a54ae106b243817 Mon Sep 17 00:00:00 2001
From: Brent Baccala
Date: Tue, 1 Nov 2016 01:07:52 -1000
Subject: [PATCH 1/2] rpctrace: don't wrap send-once rights s
package actually get built? Is there a script?
I don't know. There are debian/make-new-orig.sh and
debian/make-new-tarball.sh but those do not seem to do all the
steps.
> I was just reading about "git-buildpackage", which manages
> Debian patches by converting them back and
s approach been deliberately rejected?
And then, of course, the Debian patches are checked into git as files, not
(git) patches. I was just reading about "git-buildpackage", which manages
Debian patches by converting them back and forth to git patches on a
dedicated branch. You keep t
"Brent W. Baccala" writes:
> My first question is for advice on managing my workflow. I'm using the
> Debian hurd package, which adds patches on top of a snapshot taken from
> savannah's git tree. I think I want to work on the Debian-ized code, since
> that'
Hi :)
[PATCH 1/5] libihash: fix typo
[PATCH 2/5] libihash: add hurd_ihash_get_load
This also makes the description of binary percent more prominent.
[PATCH 3/5] libihash: add hurd_ihash_value_valid
[PATCH 4/5] libihash: optimize lookup-or-insert operations
I'm replacing the node caches in {ext2
On Mon, Apr 7, 2014 at 8:55 PM, Samuel Thibault wrote:
> Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit :
> > On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault >
> > wrote:
> >
> > Again, no. Drivers can work the way they prefer. The driver
> > infrastructure itself doesn't need a
Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit :
> On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault
> wrote:
>
> Again, no. Drivers can work the way they prefer. The driver
> infrastructure itself doesn't need a "bigplan", it is parts of it which
> need their own. For instan
On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault wrote:
>
> Again, no. Drivers can work the way they prefer. The driver
> infrastructure itself doesn't need a "bigplan", it is parts of it which
> need their own. For instance, the IRQ issue I mentioned has its plan
> by itself, and it doesn't need
Zhang Cong, le Mon 07 Apr 2014 19:36:02 +0800, a écrit :
> On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault
> wrote:
>
> Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit :
> > Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit :
> > > The one who do this need have the f
On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault wrote:
> Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit :
> > Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit :
> > > The one who do this need have the full plan,
> >
> > I don't see why one would need a full plan.
>
> Putting it
ed to know *all* the code to review the
> patch, ping people about what is wrong with it, clean it, etc.
I reserve my opinion here.
> > How about we make a upstream branch and do fast iterator merge and other
> stuff,
> > we review this branch but not the patches, whe
On Mon, Apr 7, 2014 at 5:57 PM, Samuel Thibault wrote:
> And what is the solution? I *DONT* have the time to fix it all myself.
> It's as simple as that. What can I do more about it?
I believe Samuel has already squeeze his time to make the current bright
hurd, thanks.
Samuel, If we don't
Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit :
> > I end up spending my time mostly fixing & pushing more-or-less-baked
> > patches to Debian packages, so people at least get to try them, but the
> > polishing+submitting work is much more work, and if nobody give
Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit :
> Quoting Samuel Thibault (2014-04-07 01:02:56)
> > As for the two other stuff in the Debian hurd package (random,
> > procfs), yes it is a ugly hack, and I'd rather avoid it. It was
> > just a way to get working /dev/random and /proc so
Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit :
> I believe that it is essential to reduce every bit of overhead
> possible from the development process.
Again, I fully understand that. It just happens that I spend mostly all
of my available time doing:
- fix the few bits without whi
ran a
> debian system at all. Of course we should think about just merging
> them into the main repository, or build them another way, etc. I
> for myself have never found the time to even just think about it.
Yes please. I never understood why those are in separate
repositories.
> I e
Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit :
> Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit :
> > The one who do this need have the full plan,
>
> I don't see why one would need a full plan.
Putting it another way, I don't think anybody has the full plan. Which
is fin
ith it, clean it, etc.
> How about we make a upstream branch and do fast iterator merge and other
> stuff,
> we review this branch but not the patches, when it's OK, merge the branch
> to
> the main upstream branch or just use it as the main upstream branch?
Be it a
appily do it. Yes, it means spending time on how
> to do it, but if nobody else spends it, I'll have to do it, but god
> knows when I'll find time to do it among all other urging matters.
>
> It's a time matter, and have improve space, I can understand how this is
a challe
Put yet another way, if you ask me "why isn't foo done?" I'll most
probably just answer "because I haven't had time to do it, and nobody
else took the time to do it. If you ask me "could foo be done
then?", I'll answer "sure, patch welcome". If you ask me "I've had a
look, we could just apply thi
Ludovic Courtès, le Sun 06 Apr 2014 22:44:12 +0200, a écrit :
> Indeed, few of the patches at
> <http://patch-tracker.debian.org/package/hurd/1:0.5.git20140326-1> look
> Debian-specific.
>
> For features that are not “fully baked” yet, like DDE, wouldn’t it make
> sense
Indeed, few of the patches at
<http://patch-tracker.debian.org/package/hurd/1:0.5.git20140326-1> look
Debian-specific.
For features that are not “fully baked” yet, like DDE, wouldn’t it make
sense to have a branch in the Hurd repo, instead of a set of patches in
Debian?
As for patches for
Samuel Thibault, le Mon 07 Apr 2014 01:02:56 +0200, a écrit :
> Put another way, please people just dive into patches,
Put yet another way, if something is eating time in your workflow for no
apparently good reason, there was probably no good reason except lack of
time for doing things better,
nter, le Sun 06 Apr 2014 19:58:45 +0200, a écrit :
> > >>> I'd like to see more of the debian/patches merged, especially the
> > >>> exec_filename_* series.
> > >>
> > >> The discussion about it with Roland was unfortunately not finished
get working /dev/random and /proc so people can ran a debian system at
all. Of course we should think about just merging them into the main
repository, or build them another way, etc. I for myself have never
found the time to even just think about it.
I end up spending my time mostly fixing & pus
Quoting Emilio Pozuelo Monfort (2014-04-07 00:38:28)
> On 07/04/14 00:26, Justus Winter wrote:
> > Hi,
> >
> > Quoting Samuel Thibault (2014-04-06 21:25:42)
> >> Justus Winter, le Sun 06 Apr 2014 19:58:45 +0200, a écrit :
> >>> I'd like to see mo
On 07/04/14 00:26, Justus Winter wrote:
> Hi,
>
> Quoting Samuel Thibault (2014-04-06 21:25:42)
>> Justus Winter, le Sun 06 Apr 2014 19:58:45 +0200, a écrit :
>>> I'd like to see more of the debian/patches merged, especially the
>>> exec_filename_* seri
Hi,
Quoting Samuel Thibault (2014-04-06 21:25:42)
> Justus Winter, le Sun 06 Apr 2014 19:58:45 +0200, a écrit :
> > I'd like to see more of the debian/patches merged, especially the
> > exec_filename_* series.
>
> The discussion about it with Roland was unfortuna
As I said in the irc it would be really helpfull if the debian patches
got merged with the upstream. Right now whenever I get an error, I am
searching in them, handpicking the part that solves it. Actually some
of the debian patches are necessary to built glibc and libpthread. I
will report
1 - 100 of 276 matches
Mail list logo
