Re: MRE request: virtualbox

[Gianfranco Costamagna]

Hello, since there might be some new SRU ongoing of virtualbox, it would be 
nice if you can have another look to this...
Or to let me know if something is not clear or still missing!

Have a great day

Gianfranco






Il giovedì 29 febbraio 2024 alle ore 09:44:15 CET, Gianfranco Costamagna 
 ha scritto: 





Hello Christopher thanks for the huge work!


>Sorry for the delay in addressing this.

No need to be sorry at all, we are all under high work load, and I appreciate 
you all taking the steps to finally solve this long
standing issue. Let's try to finish it! :)

>This does seem like Virtualbox fits well enough in the HWE category (and 
>probably has sufficient upstream testing) for special SRU treatment.
>
>I've taken the liberty of reworking the wiki page 
>https://wiki.ubuntu.com/VirtualboxUpdates to make it easy to review and 
>accept Virtualbox SRU bugs. I've done this to the best of my 
>understanding, but you're the domain expert, so please check my work :)

If you didn't understand something, it means I wasn't clear enough, so thanks
for adding another pair of eyes

>Particularly: it's my understanding that this does *not* require any 
>special coordination with the kernel - the Ubuntu kernel contains 
>Virtualbox guest driver modules, but these are upstream kernel modules, 
>and the Ubuntu kernel build does not build virtualbox-dkms modules at 
>kernel-build time¹

Yes and no.
Virtualbox ships both host and guest dkms modules. People might want to install
guest-dkms even if they are provided by the kernel (they shuld have an higher 
priority)

Reasons might be multiple, bugs in upstream dkms module, or better behaviour.
I don't recall having issues with upstream guest dkms modules, but I didn't want
to drop it because of older kernels being still around, and for safety reasons.

For *host* kernel module this is sadly a little bit trickier. Newer kernel might
break vboxdrv.ko buildability, so for each new kernel, the dkms autopkgtests
should be looked at carefully for regressions (in both host and guest).


>I've also marked a couple of places (with ***s) where the test case 
>instructions were not clear to me. The intent with test case 
>documentation is that it should be detailed enough that anyone reading 
>the bug could perform the steps and we could be confident that they have 
>exercised the expected tests.

I fully agree and sorry for not being clear enough, I do this testing in an 
automatic
way on my head, so I'm pretty sure I missed lots of things.

>Specifically, the questions I had were:
>
>* instructions for installing/removing the guest additions from the iso 
>pack (or pointers to documentation for that)
>
>* What the “various other tests” are - you mention changing 
>configuration and vboxmanage?
>
>* Do we need to verify that installing virtualbox guest packages 
>*outside* a VM does not interfere with the system? There seems to have 
>been at least one bug raised about that in the past.

I don't recall such issues, but in any case didn't have such reports in the 
last like 5-10 years...
I'll add it in case, just to be extra safe.

>Sorry again for the delay,

Sorry again from my side for not putting the page in a clear enough way, it 
would have made things easier for
all of us :)

Feel free to have another look, the page will be updated in some minutes.


Gianfranco

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: MRE request: virtualbox

[Gianfranco Costamagna]

Hello Christopher thanks for the huge work!


>Sorry for the delay in addressing this.

No need to be sorry at all, we are all under high work load, and I appreciate 
you all taking the steps to finally solve this long
standing issue. Let's try to finish it! :)

>This does seem like Virtualbox fits well enough in the HWE category (and 
>probably has sufficient upstream testing) for special SRU treatment.
>
>I've taken the liberty of reworking the wiki page 
>https://wiki.ubuntu.com/VirtualboxUpdates to make it easy to review and 
>accept Virtualbox SRU bugs. I've done this to the best of my 
>understanding, but you're the domain expert, so please check my work :)

If you didn't understand something, it means I wasn't clear enough, so thanks
for adding another pair of eyes

>Particularly: it's my understanding that this does *not* require any 
>special coordination with the kernel - the Ubuntu kernel contains 
>Virtualbox guest driver modules, but these are upstream kernel modules, 
>and the Ubuntu kernel build does not build virtualbox-dkms modules at 
>kernel-build time¹

Yes and no.
Virtualbox ships both host and guest dkms modules. People might want to install
guest-dkms even if they are provided by the kernel (they shuld have an higher 
priority)

Reasons might be multiple, bugs in upstream dkms module, or better behaviour.
I don't recall having issues with upstream guest dkms modules, but I didn't want
to drop it because of older kernels being still around, and for safety reasons.

For *host* kernel module this is sadly a little bit trickier. Newer kernel might
break vboxdrv.ko buildability, so for each new kernel, the dkms autopkgtests
should be looked at carefully for regressions (in both host and guest).


>I've also marked a couple of places (with ***s) where the test case 
>instructions were not clear to me. The intent with test case 
>documentation is that it should be detailed enough that anyone reading 
>the bug could perform the steps and we could be confident that they have 
>exercised the expected tests.

I fully agree and sorry for not being clear enough, I do this testing in an 
automatic
way on my head, so I'm pretty sure I missed lots of things.

>Specifically, the questions I had were:
>
>* instructions for installing/removing the guest additions from the iso 
>pack (or pointers to documentation for that)
>
>* What the “various other tests” are - you mention changing 
>configuration and vboxmanage?
>
>* Do we need to verify that installing virtualbox guest packages 
>*outside* a VM does not interfere with the system? There seems to have 
>been at least one bug raised about that in the past.

I don't recall such issues, but in any case didn't have such reports in the 
last like 5-10 years...
I'll add it in case, just to be extra safe.

>Sorry again for the delay,

Sorry again from my side for not putting the page in a clear enough way, it 
would have made things easier for
all of us :)

Feel free to have another look, the page will be updated in some minutes.

Gianfranco

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Fw: MRE request: virtualbox

[Gianfranco Costamagna]

Hello, I found that an MRE request was acked in 2015 for virtualbox, but since 
then, the workflow has changed a lot, so
I'm asking again for an MRE exceptiom related to virtualbox.
I already created the wiki page with the process, I will try to update it to 
match the current expectation criteria

https://wiki.ubuntu.com/VirtualboxUpdates

thanks for considering it

G.






- Messaggio inoltrato -

Da: Martin Pitt 
A: "costamagnagianfra...@yahoo.it" 
Cc: "technical-bo...@lists.ubuntu.com" ; 
"secur...@ubuntu.com" 
Inviato: mercoledì 4 novembre 2015 alle ore 02:26:02 CET
Oggetto: Re: MRE request: virtualbox


Hello Gianfranco,

Gianfranco Costamagna [2015-10-29 18:50 +0100]:
> I would like to apply for a micro release exception for Virtualbox

Since [1] we actually did away with (most) explicit MREs, and adjusted
the SRU policy to generalize those.

[1] 
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html

> Upstream:
> 
>  - Micro releases happen from low-volume stable branches,
>    approximately once every two months.
> 
>  - Stable branches are supported with bug fixes for some years
> (normally 5 years + 6 months or more).
> 
>  - Upstream commits are reviewed by members of the Virtualbox Server
>    Engineering team.
> 
>  - All commits to stable branches are evaluated wrt. potential
>    regressions and signed off by the Virtualbox team.
> 
>  - Unit tests and regression tests are run on multiple platforms per
>    push to the source code repository. In addition, there are more
>    extensive test suites run daily and weekly.
> 
>  - Each micro release receives extensive testing between code freeze
>    and release. This includes the full functional test suite,
>    performance regression testing, load and stress testing and
>    compatibility and upgrade testing from previous micro and
>    minor/major releases.
> 
>  - Tests are run on all supported platforms (currently amd64 and i386).

This satisfies the current policy, so this looks fine for SRUing.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: mlt has an incomplete/incorrect tarball

[Gianfranco Costamagna]

Hello, I suggest to ask Debian maintainer how to better solve it. 
You can1 ask upstream to do a new release and tag 2 repack the source adding it 
with +repack suffix3 pack the complete tarball with a different compression 
algoritm4 use multiple tarballs for your source (e.g. Nodejs) 
In any case better ask and do it on Debian first and then sync, otherwise we 
will be bitten by mismatches of tarball checksums. 
G. 

Sent from Yahoo Mail on Android 
 
  On Sat, Aug 27, 2022 at 6:57, Erich Eickmeyer wrote:   
 
Hi all,


During my testing this evening of kdenlive 22.08, I found two issues:


kdenlive now needs a recommends on mediainfo. No big deal, bug filed (LP: 
#1987934), I can practically take care of that in my sleep.


However, it also needs a module in mlt: glaxnimate. Upon investigation, 
glaxnimate requires a build-dep on qt5base-dev and a build flag enabled 
(-DMOD_GLAXNIMATE=ON). It was at this point that I discovered that the 
glaxnimate submodule is *entirely missing* from the source tarball, and that 
the wrong tarball was grabbed by the Debian maintainer upstream from 
https://github.com/mltframework/mlt/releases/tag/v7.8.0. It seems as though the 
maintainer grabbed the github tagged source code tarball (released June 22nd) 
and not the intended tarball with all submodules, which came later (July 3rd).


Since this tarball is obviously incorrect, how do we fix this situation? The 
maintainer will obviously have to be alerted to the error, but that doesn't 
solve the immediate problem with versioning in the archive. As this is a 
universe package, I'm more than happy to take care of it as long as I know how 
to version it.


I can take care of all the necessary steps to write a bug report on this, but 
this seemed like a unique situation that I needed some advice on first, and 
seemed like it needed more explanation than I can provide on IRC.


Thanks,

Erich


-- 

Erich Eickmeyer

Project Leader - Ubuntu Studio

Member - Ubuntu Community Council
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
  
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: On a Debian package depended on Java 8 but anymore

[Gianfranco Costamagna]

Hello,


>Sorry for bothering you again.  So now a newer package of I2P is in
>
>Ubuntu "proposed" (I figure this is something like Debian testing).
>
>https://launchpad.net/ubuntu/+source/i2p


it simply fails to build :)
https://launchpadlibrarian.net/366409593/buildlog_ubuntu-bionic-amd64.i2p_0.9.33-2_BUILDING.txt.gz

>It's been there for 10 days.


>To put it into Bionic, should I just wait for a while?  Or need to do
>something manually?  Or is it too late?  I really appreciate if a
>newer package can be put into Bionic because of Java 8/9 problem. I
>read https://wiki.ubuntu.com/SyncRequestProcess, but if missed
>something (I should say I'm still a bit confused about how to use
>requestsync) I'm sorry and appreciate if you could tell me the way to
>go.


it was good, but it needs to build in order to migrate :P

I'm quick and dirty fixing it to let the package migrate, feel free to fix in 
the proper way
and send me a patch (or upload it to Debian!)

thanks for the contribution to Ubuntu

Gianfranco

2018-04-10 23:33 GMT+09:00 Masayuki Hatta :

> Hi Jeremy,

>

> Thanks a lot for info!  I didn't even know there's ubuntu-dev-tools in

> Debian :-)

>

> Best regards,

> MH

>

> 2018-04-09 1:26 GMT+09:00 Jeremy Bicha :

>> On Sun, Apr 8, 2018 at 11:05 AM, Masayuki Hatta  wrote:

>>> May I request so, following

>>> https://wiki.ubuntu.com/DebianImportFreeze? I understand it's way too

>>> late, or is there any chance I can update Ubuntu package in Bionic

>>> later?

>>

>> Thank you for taking interest in helping make Ubuntu better!

>>

>> I see that an Ubuntu developer has synced the package for you now.

>> Next time, I recommend that you use the requestsync script (part of

>> ubuntu-dev-tools which is available in Debian).

>>

>> References

>> 

>> https://wiki.ubuntu.com/SyncRequestProcess

>> https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers

>> https://manpages.debian.org/requestsync

>>

>> Thanks,

>> Jeremy Bicha

>

>

>

> --

> Masayuki Hatta

> Associate Professor, Faculty of Economics and Management, Surugadai

> University, Japan

>

> http://about.me/mhatta

>

> mha...@gnu.org  / mha...@debian.org / mha...@opensource.jp /

> hatta.masay...@surugadai.ac.jp




-- 

Masayuki Hatta

Associate Professor, Faculty of Economics and Management, Surugadai

University, Japan


http://about.me/mhatta


mha...@gnu.org  / mha...@debian.org / mha...@opensource.jp /

hatta.masay...@surugadai.ac.jp


-- 

Ubuntu-release mailing list

Ubuntu-release@lists.ubuntu.com

Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: xchat and hexchat

[Gianfranco Costamagna]

Hello Steve and all,


>Lacking quorum, there was no actual TB meeting the other week.  However, as
>I noted on IRC, I also don't consider this a matter requiring the Technical
>Board's input.  In the first instance, this falls within the purview of the
>archive team, and I'm happy for us to field it as such.


I agree, thanks for simplifying the things :)
>If there are concerns about the archive team's decision here, that decision
>may always be appealed to the TB.
>
>The original bug report,
>, was filed
>per my request on #ubuntu-release[1], but I overlooked the actual filing
>which came with some delay after the IRC discussion.
>
>This does not mean I agree that the package should be removed, but as you, I
>think it's important to have this discussion and take a decision.


thanks
>I do have concerns about the quality of this software, as well as about the
>maintainer's response to the concerns that have been raised.  Comments
>inline:


lets try to answer

>An IRC client, in its default mode of operation, requires zero>authentication 
>of a remote server.  The server must therefore be considered
>untrusted and potentially hostile.  Even *with* authentication, a remote
>server could be compromised.
>
>Any security vulnerability involving a network client failing to validate
>input from a remote source is a significant one.
>
>And in my opinion, any network client whose upstream maintainer didn't
>consider such vulnerabilities worthy of serious attention should not be
>included in a stable Ubuntu release.
>
>So please don't try to argue for xchat's inclusion by downplaying the
>significance of security vulnerabilities.


ack here, but sorry if I made this false assumption. the mean of that
sentence was not "don't care because internet is broken or evil",
but more a "hey, such vulnerabilities exists in probably *all* irc clients,
including hexchat and others, at least in stable releases. You can do fuzzy
testing against the versions to check them.

So, while I *always* fixed CVEs on my packages, I also think we should focus
more to real bugs, not something discovered by a fuzzy test, that affects 
probably
most irc clients, with an userbase really low, and with a crash as effect and 
not
a personal data leak or similar.

My assumption was just to mention that a "crash" for a vulnerability is 
something
we might really like at the end :)

>I have no problem in principle with a package that is orphaned upstream and
>is now maintained only in Debian/Ubuntu.  There have certainly been many
>other examples of this, and such packages are not categorically worse than
>those that have a separate upstream.
>
>My understanding is that most former xchat users find hexchat to be a
>reasonable replacement.  Can you explain why you do not?


it is, but new features breaks it from time to time (eg. 1.14.0 vs 1.14.1, the 
latter
has been pushed because of the previous one not being suitable for usage), 
moreover
we still don't have a clean upgrade path from xchat to hexchat, at least for 
configuration files.

People might want to keep it, until we smoothly upgrade them and move around 
configuration.
(this is something somewhat slowly ongoing=

>I'm afraid I don't agree at all with this argumentation.  For better or
>worse, it is a fairly common practice across Free Software (and otherwise!)
>for security vulnerabilities to be fixed by upstreams without disclosing
>these were security vulnerabilities; and this doesn't have to indicate ill
>intent on the part of the upstream.  Sometimes the upstream has nothing more
>than a vague sense that a bug might be exploitable and it's not worth the
>effort to prove it.
>
>I don't think it in any way disqualifies hexchat for inclusion in stable
>Ubuntu releases to know that upstream has fixed security bugs without going
>through a particular disclosure process.  It is not even the responsibility
>of the upstream maintainer to notify Ubuntu of such vulnerabilities (though
>we certainly welcome having such notifications!), and for packages in
>universe, many known vulnerabilities will unfortunately remain unfixed
>anyway.  It is definitely not the upstream's responsibility to disclose the
>details of security vulnerabilities for the benefit of an unrelated fork
>from an older codebase.


sure, this wasn't a really strong point on my side :)

>I do question the wisdom of maintaining software exclusively via
>debian/patches over the long term, if indeed that's what you're doing here. 
>But that's my personal opinion as a developer, and has nothing to do with
>whether the package, today, should be removed from the release.


ack

>What, in practice, do you believe this maintenance will consist of?  Are you
>planning to monitor CVE activity of related codebases to watch for issues
>that may also affect xchat, or will this maintenance be entirely reactive in
>response to critical bug reports?


yes, as I'm doing with all the 

Re: xchat and hexchat

[Gianfranco Costamagna]

Hello,

>I've added this to the TB agenda. I imagine it'll take quite a bit of
>reading of the various references (I've added them to the agenda item)
>so appreciate you may not be able to decide by tomorrow's meeting.


just to give my quick maintainer point of view.

1) the security issues it has, are also applicable to hexchat (we will upload
a fixed hexchat soon, upstream after all this debate quickly found and fixed 
some issues
and released a new upstream tarball)

this said, the security issues, can crash hexchat or xchat if you connect to a 
malicious
server, sending non standard irc replies.
(so, an exceptional use case I would say)

2) the package is not upstream maintained but it is fully Debian/Ubuntu 
downstream maintained.
I did fix a lot of bugs, and did ~10 uploads in the archive, making it suitable 
again for
release (in my maintainer opinion, feel free to have whatever different opinion)

3) I still need to reproduce the ctrl+i crash, I failed so far
4) see my point here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891982#35
5) having 40 patches is a complete nonsense, what is the problem if somebody is 
willing to maintain
it that way?
would it be better if I create a new "upstream" release and upload a no-patch 
package? it would end
up in a similar result, I don't see the difference
6) I'm willing to maintain it for bionic lifespan.
7) people debating about something is not a good reason from stopping adoption 
or remove it
(cfr: init systems war :p )
8) both upstream/hexchat and Ubuntu/xchat maintainers opinion are biased, so, 
consider that here
I'm just making a point for xchat, not against.


just my .02$, feel free to do whatever your hat demands to do, I'll happily 
accept any decision
you will take on this matter :)
(I'll continue to maintain it in my ppa anyway, unless you ask me to stop doing 
it :p )

thanks for reading,
(Robie, please bounce the email in case it doesn't reach the two lists)

Gianfranco

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release