Code Monkey home page Code Monkey logo

lilac's People

Contributors

a-wing avatar asukaminato0721 avatar axionl avatar bennyyip avatar cuihaoleo avatar ddosolitary avatar ehfive avatar farseerfc avatar felixonmars avatar lilacbot avatar lilydjwg avatar marvelousblack avatar oowl avatar pekkarr avatar petronny avatar renyuneyun avatar roaldclark avatar samlukeyes avatar silverrainz avatar starsareintherose avatar void001 avatar xuanwo avatar yan12125 avatar yuyichao avatar zsrkmyn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lilac's Issues

Should lilac do a clean up after `makepkg -od`?

I encountered a problem yesterday that the moe lilac sent me a e-mail to remind me the that vim-youcompleteme-git was failed to build AGAIN! The error occured while runing makepkg -od.

I did a research and found it was mainly due to the existing of the old $srcdir generated by last runing of makepkg -od, and a patch was applied twice:

==> 正在开始 prepare()...
  -> Setting up Git submodules...
patching file YouCompleteMe/autoload/youcompleteme.vim
patching file ycmd/default_settings.json
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file ycmd/default_settings.json.rej
==> 错误: 在 prepare() 中发生一个错误。
    正在放弃...

Since the file to be patched is actually in a git submodule, It keeps patched (but not reset to the origin one at the process of extracting sources) at the second time makepkg -od running. The submodule in PKGBUILD is initialized as the wiki says.

I think about some solutions, but don't know which is best:

  • Force clean up the submodule dircetories before git submodule init in PKGBUILD. However, this is unnacessary in most cases and may make PKGBUILD a little bit confusing.
  • Clean up the $srcdir (or more specifically, remove it) in lilac.py. However, due to the different setting of BUILDDIR in ~/.makepkg.conf or /etc/makepkg.conf, it is not easy to obtain the location where the $srcdir is.
  • Use makepkg -od --noprepare here. This is a bit tricky and since pkgver() is executed after prepare(), pkgver may be wrongly acquired by lilac due to the skip of prepare().
  • Use makepkg -odc at the line mentioned above. This force makepkg remove the $srcdir after obtaining the sources and running pkgver() to update PKGBUILD. (I prefer this)

So, which one is preferable?

循环依赖的问题

就是现在有两个包a, b
第一个需要

depends=['b']

第二个需要

depends=['a']

这时候lilac会怎么处理呢?

PS. 严格来说ab的依赖,ba的可选依赖,但是如果b作为a的依赖的话,a会开启额外的编译支持

*-build报错的时候,会把*-build的内容发送两遍

如题
一开始的时候

命令执行失败!

命令 ['extra-x86_64-build', '--', '-I', 
...
 '--', '--holdver'] 返回了错误号 255。命令的输出如下:

:: Synchronizing package databases...
 core is up to date
 extra                   1653.9 KiB  11.3M/s 00:00 [######################] 100%
 community                  4.5 MiB  11.2M/s 00:00 [######################] 100%

之后

编译命令输出如下:
:: Synchronizing package databases...
 core is up to date
 extra                   1653.9 KiB  11.3M/s 00:00 [######################] 100%
 community                  4.5 MiB  11.2M/s 00:00 [######################] 100%

感觉十分冗余。。。

[Feature request]使updpkgsum变成update_pkgver_and_pkgrel的可选项

我手上有些包可以从网上自动下载sum...比如说类似于这样的PKGBUILD

_sha1="$(curl https://www.giss.nasa.gov/tools/panoply/download/Panoply-${pkgver}.sha1.txt 2>/dev/null | grep 'PanoplyJ..zip' | grep -o '^[^ ]')"
sha1sums=("${_sha1}"
...
update_pkgver_and_pkgrel貌似会强制makepkg -g 然后updpkgsum,不知道可不可以让它变成可选项。默认还是自动updpkgsum啦,但是如果能够给定一个参数的话,可以只update pkgver,不update sum

发生未知错误!NameError: name 'bp' is not defined

好几个软件包(anaconda, docear, cppreference-qt, android-sdk-build-tools) 4:40 PM收到lilac发的错误邮件,内容都一样:

发生未知错误!调用栈如下:

Traceback (most recent call last):
File "/home/lilydjwg/bin/lilac", line 89, in build_package
depends = DEPENDS.get(package, ()),
File "/home/lilydjwg/soft/lilac/lilaclib.py", line 351, in lilac_build
call_build_cmd(bp, depend_packages, pkgs_to_build)
NameError: name 'bp' is not defined

不知道是不是已经修复?

auto bump pkgrel when rebuilding a package

如题,我在mpv-git使用的auto bump代码感觉效果还挺好的。。。
我正在想可不可以把那个设置成默认的行为?

目前想到的问题有:

  1. 原来的自动保留大pkgrel的功能感觉需要去掉
  2. 需要一种新的手动trigger rebuild的方式(比如通过创建一个空的rebuild文件)

recv_gpg_keys() goes wrong in single_main mode.

Here is the traceback:

[D 01-20 18:19:43.732 lilaclib:386] running ['recv_gpg_keys'], not using pty, showing output
Traceback (most recent call last):
  File "lilac.py", line 13, in <module>
    single_main()
  File "/home/stephen/worktmp/lilac_test/lilaclib.py", line 380, in single_main
    accept_noupdate = True,
  File "/home/stephen/worktmp/lilac_test/lilaclib.py", line 282, in lilac_build
    recv_gpg_keys()
  File "/home/stephen/worktmp/lilac_test/lilaclib.py", line 453, in recv_gpg_keys
    run_cmd(['recv_gpg_keys'])
  File "/home/stephen/worktmp/lilac_test/lilaclib.py", line 394, in run_cmd
    p = subprocess.Popen(cmd, stdout = stdout, stderr = subprocess.STDOUT)
  File "/usr/lib/python3.4/subprocess.py", line 858, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.4/subprocess.py", line 1456, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'recv_gpg_keys'

And here, I find a way to solve it:

diff --git a/lilaclib.py b/lilaclib.py
index b3a3c21..f9f47e7 100644
--- a/lilaclib.py
+++ b/lilaclib.py
@@ -450,4 +450,4 @@ def build_prefix_to_arch(cmd):
     return 'x86_64'

 def recv_gpg_keys():
-  run_cmd(['recv_gpg_keys'])
+  run_cmd([os.path.join(os.path.realpath(os.path.dirname(__file__)), 'recv_gpg_keys')])

参数功能汇总

就是列一下要写哪些。。目前已知的有

  • -c , --config 指定config.ini
  • --no-git-push
  • --no-send-mail

还有啥

增加文件編輯(常用)工具函數

之前在寫倉庫中的lilac.py的時候,時不時會碰到PKGBUILD中部分變量(主要是dependsmekedepends)不正確/完整的問題。
雖說理論上應該等上游(對於我的幾例來說就是AUR)修改,但有時候上游修改太慢,所以有時直接就在lilac.py中修改了,直到上游修正再改回去。

這樣,那部分工具函數就要複製過來過去地,稍顯累贅。故而想是否可以將其加入lilac代碼庫中,以便重用、訂正以及更多人使用。

這裏基本上是直接將之前用的代碼複製過來,並增加了兩個入口函數(add_dependsadd_makedepends)。

如果認爲可以合併的話,現在還有兩個問題:

  1. 這個文件應該放在哪,以及叫什麼?
  2. 是否應該在次級模塊中引用lilaclib?或者是將被引用的那個函數(edit_file)移至(另一個?)次級模塊中的某個地方?

重复利用submodule

不修改PKGBUILD的前提下

$ cat update-submodules.sh
#!/bin/bash
gitname=$1
[ -z "$2" ] && branch=master || branch=$2

[ ! -d $gitname ] && makepkg --verifysource && rmdir src

cd $gitname

if [ `git config --get core.bare` == "true" ]
then
        mkdir .git
        mv * .git
        git config --local --bool core.bare false
        git checkout $branch
fi

git reset --hard HEAD~1
git pull origin $branch
git submodule update --init

for i in `git submodule status | awk '{print $2}'`
do
        git config --file=.gitmodules submodule.$i.url "$(realpath .)/$i"
done

git add .
git commit -m 'makepkg'

#extra-x86_64-build -- -D `realpath $gitname`

可以重复利用submodule

抛砖引玉了。。。

有关直接同步其他地方的binaries到repo

archlinuxcn/repo#929
除此之外我还见过某些包有不提供PKGBUILD只提供arch binaries的。

  1. 我们可以直接同步这些包到repo吗?
  2. 若可以,我们应如何实现呢?
    lilac.py直接下载可否?
  3. 对于已签名的包,直接添加key是否可以?
    对于未签名的包,我们是否要签名一次?

把run_cmd的输出导入logger

现在lilac的log转存文件那里感觉很不美观
是基于重定向的,应该是为了适配run_cmd的输出

所以我们能不能把run_cmd的输出改用logger输出?
这样我们可以只通过加一个handler就能把log转存到文件,
并且如果使用RotatingFileHandler的话,还可以只存最近若干次的log

共享 cargo 的数据

包括 register、第三方 repo、已下载的文件。如果能共享编译结果就更好的(sccache)。

syringa nvchecker failed after a successful build

syringa has been built successfully: https://build.archlinuxcn.org/packages/#/syringa

But every time lilac running, I will got an error report:

{"logger_name": "nvchecker.core", "name": "syringa", "event": "unexpected error happened", "level": "error"}
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/nvchecker/core.py", line 152, in worker
    ret = await get_version(name, conf, keyman=self.keymanager)
  File "/usr/lib/python3.7/site-packages/nvchecker/get_version.py", line 62, in get_version
    version = await func(name, conf, **kwargs)
  File "/usr/lib/python3.7/site-packages/nvchecker/source/github.py", line 24, in get_version
    check_ratelimit(e, name)
  File "/usr/lib/python3.7/site-packages/nvchecker/source/github.py", line 22, in get_version
    return await get_version_real(name, conf, **kwargs)
  File "/usr/lib/python3.7/site-packages/nvchecker/source/github.py", line 64, in get_version_real
    async with session.get(url, headers=headers, **kwargs) as res:
  File "/usr/lib/python3.7/site-packages/nvchecker/source/tornado_httpclient.py", line 62, in __aenter__
    return await to_asyncio_future(client.fetch(self.req))
tornado.httpclient.HTTPClientError: HTTP 404: Not Found

I'm not so sure what's wrong with it, can you have a look ?

无法通过参数指定只构建新的包

比如我添加了一个新的包a到repo, 然后lilac a
会报错unknown packages: {'a'}
其实是因为 No such file or directory: repodir+'/a'
理论上说只要先git pull就好了...

当PKGEXT存在时lilac会找不到打出来的包

如题
问题出在wps-office的时候

PKGEXT=".pkg.tar"
Traceback (most recent call last):
  File "/home/lilydjwg/bin/lilac", line 111, in build_package
    depends = DEPENDS.get(package, ()),
  File "/home/lilydjwg/soft/lilac/lilaclib.py", line 412, in lilac_build
    raise Exception('no package built')
Exception: no package built

让lilac的log看起来好一点。。。

#!/bin/sh
sed -e 's/^M$//g' -e 's/^.*^M//g' -e 's/^[(B//g' -e 's/^[\[[0-9]*[mK]//g' -e 's/ *$//g' -i "$@"
sed '/^____/{:i;s/\n/^M/;N;/\n____/bi;s/^.*^M//}' -i "$@"

干掉了色彩输出和各种进度条
最后一行是我在编译tensorflow时遇到的,多数情况应该不需要

zstd 支持

话说之前提到的默认用zstd做pacman默认压缩的事情咋样了啊。。。

什么时候换zstd啊,我们可以提前跟进么?

Lilac doesn't resolve dependencies recursively

This is how current Lilac resolves dependencies:

lilac/lilac2/building.py

Lines 53 to 61 in 8746570

for x in depends:
p = x.resolve()
if p is None:
if not x.managed():
# ignore depends that are not in repo
continue
need_build_first.add(x.pkgname)
else:
depend_packages.append(p)

It cannot resolve dependencies more than two layers. An example is lxqt-panel-git, whose dependency tree is:

lxqt-panel-git
  lxqt-globalkeys-git
    liblxqt-git
      libqtxdg-git
  libsysstat-git

A solution (workaround?) is using archlinux-x86_64 as the build prefix.


看了下Lilac的代碼,修好這個問題似乎得改不少地方,因此先開個坑,有空再研究。

如果上一次lilac运行出错了那么下一次lockit会出权限问题

重现方式

$git reset --hard
HEAD is now at c990c5d config.ini: don't override my env variable
$cp config.ini.sample config.ini
$./lilac
[E 09-16 22:34:24.999 lilac:462] unexpected error
    Traceback (most recent call last):
      File "./lilac", line 455, in <module>
        setup()
      File "./lilac", line 450, in setup
        os.chdir(REPODIR)
    FileNotFoundError: [Errno 2] No such file or directory: '/path/to/gitrepo'
$./lilac
[E 09-16 22:34:42.695 lilac:462] unexpected error
    Traceback (most recent call last):
      File "./lilac", line 455, in <module>
        setup()
      File "./lilac", line 440, in setup
        lockit()
      File "./lilac", line 68, in lockit
        lock = os.open(mydir+'/.lock', os.O_WRONLY | os.O_CREAT, 600)
    PermissionError: [Errno 13] Permission denied: '/home/petron/.lilac/.lock'

lilac无法添加那些package base与包不同名的包为依赖

比方说,lilac.py中指明了

depends=['python2-a']

python2-a与python-a由同一个PKGBUILD打出来的,package base叫a
所以我在repo中添加了a/PKGBUILD及a/package.list

python-a
python2-a

但是此时lilac.py的check_depends中的_check_dir无法检测到python2-a这个文件夹
于是就报错了

在lilac.py中增加build这个包的timeout

如题,希望可以

depends = ['blah']
timeout = 7200 #2h

这样

主要是最近收到了chromium-dev的报错邮件

发生未知错误!调用栈如下:

Traceback (most recent call last):
 File "/home/lilydjwg/soft/lilac/lilac", line 174, in build_package
   bindmounts = BIND_MOUNTS,
 File "/home/lilydjwg/soft/lilac/lilaclib.py", line 435, in lilac_build
   call_build_cmd(build_prefix, depend_packages, bindmounts)
 File "/home/lilydjwg/soft/lilac/lilaclib.py", line 464, in call_build_cmd
   build_output = run_cmd(cmd, use_pty=True)
 File "/home/lilydjwg/soft/lilac/lilaclib.py", line 509, in run_cmd
   r = os.read(rfd, 4096)
 File "/home/lilydjwg/scripts/python/pylib/myutils.py", line 175, in timed_out
   raise TimeoutError
TimeoutError

然后我在build机上完整build了一遍

archlinuxcn-x86_64-build  115740.41s user 4526.14s system 2245% cpu 1:29:16.75 total

single_main似乎未考慮depends?

在調整其他時發現,api.py中的single_main()函數調用lilac_build()時未傳入depends參數。

所以這個意思是當使用single_main()depends = [...]不會被考慮?還是說我漏掉了什麼東西?

有关依赖缺失的报错邮件不太好

情况是包a是包b的依赖,包b是包c的依赖
所以b/lilac.py

depends = ['a']

c/lilac.py

depends = ['b']

然而如果此时a不存在的话,会产生报错邮件

软件包 b 的 lilac.py 指定了 depends,然而其中的 [Dependency(pkgdir=PosixPath('/path/to/repo/a'), pkgname='a')] 并不在本仓库中。

这个没什么问题,但还会收到一封

软件包 c 的 lilac.py 指定了 depends,然而其中的 [Dependency(pkgdir=PosixPath('/path/to/repo/a'), pkgname='a')] 并不在本仓库中。

这个就有一点迷惑了,因为c/lilac.py中并没有写

depends = ['a', 'b']

Dangling `git_push` in lilac2/api.py

lilac2/api.py 的第27行,有一個單獨成行且非調用的 git_push

不知它在那是什麼用處?
我看 cmd.py 裏它是一個函數,所以好像這樣放在那沒任何用?

[讨论] lilac的Logo

我的朋友Canplayer(昵称)决定为lilac设计一组Logo。现在草案有如下几个(原谅我没有整齐地排列它们),有建议、抑或需要完全重新设计可以提出,也请一同决定最后的Logo样式。Logo暂定为CC-BY 3.0协议。
image

-------------------------分割线-------------------------
@lilydjwg @MarvelousBlack @OriginCode 朋友给加了包之后是这样
image

-------------------------分割线-------------------------
使用打包丝带的版本:
image

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.